Skip to main content
Glama

FoxNose Knowledge

by net.foxnose
OverviewDiscussionsAdmin

Server Details

Hybrid search, schema introspection and record read/write over FoxNose collections

Ownership verified
Status
Healthy
Uptime
90.1% over 21 days
Last Tested
Transport
Streamable HTTP · MCP 2025-03-26
URL

TDQS

A4.2/5.0

Scored across 7 tools

Disambiguation4/5

Each tool has a distinct purpose, and descriptions cross-reference when to use one over another (e.g., query_records for field conditions, search_records for natural language). query_records and search_records are the only pair that could be confused, but their use-case guidance is clear.

Naming Consistency5/5

All tools follow a strict verb_noun pattern in snake_case, with singular nouns for single-item operations (get_record, update_record) and plural nouns for multi-item operations (query_records, discover_resources). This makes the set highly predictable.

Tool Count5/5

Seven tools is well-scoped for a knowledge/record management server. Each tool covers a distinct concern—discovery, schema inspection, create, read, update, structured query, and semantic search—without redundancy or bloat.

Completeness3/5

The set covers discover, describe, create, get, query, search, and update, but there is no delete_record tool, leaving a notable gap in the record lifecycle. Raising limit for counting works but there is no dedicated count or pagination helper beyond cursors.

Available Tools

7 tools
create_recordAInspect

Create a record in a collection and publish it immediately. data must match the collection schema (inspect it with describe_resource). Returns the resource_key to use with get_record/update_record. Requires the CREATE permission on this API.

ParametersJSON Schema
NameRequiredDescriptionDefault
keyNoOptional external identifier for deduplication; creating a second record with the same key returns a conflict.
dataYesDocument body matching the collection schema.
parentsNoParent placeholders for nested collection resource_ids.
collectionYesCollection resource_id from discover_resources.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but do not cover side effects like immediate publication or permission requirements. The description discloses that the record is 'publish it immediately,' requires CREATE permission, and returns a resource_key for later use. These are behavioral traits beyond the annotations, adding useful context for the agent.

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 concise and front-loaded with the primary purpose. It provides essential usage details in a few sentences without redundancy. Every sentence adds value: purpose, schema constraint, return value, and permission.

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 absence of an output schema, the description explains the return value (resource_key) and its use in subsequent operations. It covers the core requirements for calling the tool: schema matching, permission, and immediate publication. It could mention error handling or edge cases, but the essential information for correct invocation is present.

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 parameters. The description reiterates that 'data must match the collection schema' and mentions the key for deduplication, but does not add substantial new meaning beyond what the schema provides. Baseline 3 is appropriate when the schema carries the parameter documentation burden.

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?

The description clearly states the action: 'Create a record in a collection and publish it immediately.' It identifies the resource (record/collection) and the effect (publish). It also distinguishes from siblings by mentioning get_record/update_record for subsequent operations, which implies this is the creation entry point.

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?

The description provides clear usage context: 'data must match the collection schema (inspect it with describe_resource)' gives a prerequisite, and 'Requires the CREATE permission' sets an access condition. It also mentions the return value for follow-up calls, but does not explicitly state when not to use this tool or name alternative creation tools (none exist among siblings). This is strong guidance but lacks explicit exclusions.

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

describe_resourceA
Read-onlyIdempotent
Inspect

Return schema and searchability for a resource_id. Call it before filtering or sorting, to learn the field names and which fields are searchable. Searching by text does not need it.

ParametersJSON Schema
NameRequiredDescriptionDefault
parentsNoParent placeholders for nested resource_id templates.
resource_idYesResource identifier from discover_resources.

Output Schema

ParametersJSON Schema
NameRequiredDescription
nameNo
pathNo
aliasNo
actionsNo
schema_keyNo
descriptionNo
json_schemaYesJSON Schema of the record body. Reference fields appear as plain strings; nothing here marks them as references.
resource_idYes
content_typeNo
required_parentsNo
searchable_fieldsNo
schema_version_keyNo
non_searchable_fieldsNo

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description only needs to add context. It discloses that the tool returns schema and searchability info, consistent with a read-only introspection tool, but adds no further behavioral detail such as error behavior or performance characteristics.

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?

Three sentences, zero filler: the purpose is front-loaded, followed by when to call and when not to. Every sentence earns its place.

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?

Output schema exists so return values need no explanation; annotations carry the safety profile; and the description covers purpose, timing, and counter-indications. For a low-complexity, single-required-parameter introspection tool, nothing an agent needs is missing.

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, including that resource_id comes from discover_resources. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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 a specific verb and resource ('Return schema and searchability for a resource_id'), clearly positioning it as a metadata-introspection tool. This differentiates it from the CRUD and search siblings (get_record, search_records, query_records) without needing to inspect 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?

Gives explicit when-to-use guidance ('Call it before filtering or sorting') and an explicit when-not-to-use exclusion ('Searching by text does not need it'). While it doesn't name a sibling tool, the instructions are concrete, actionable, and leave nothing to inference.

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

discover_resourcesA
Read-onlyIdempotent
Inspect

List available Flux resources and capabilities. Start here: every other tool takes a resource_id from this list, and a resource's capabilities say which of them it will accept.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
apiYesPrefix of the Flux API these resources are reached through.
resourcesYes
usage_rulesNo

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the behavioral context that this is the canonical source for resource_ids and capabilities, which is useful. However, it doesn't describe the output structure or whether the list is exhaustive, though the output schema likely covers that.

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?

Two sentences with zero waste. The first sentence states the action and resource; the second sentence front-loads the critical usage guidance. Every word earns its place.

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?

For a zero-parameter discovery tool with a rich output schema and annotations covering safety, the description is nearly complete. It explains the tool's role in the overall workflow. The only minor gap is not explicitly stating that the output is a list of resource objects, but the output schema covers that.

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

Parameters4/5

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

The tool has zero parameters, so the schema is trivially complete. The description adds meaning by explaining that the output (resource_ids and capabilities) is the input to every other tool, which is valuable context beyond the empty schema. Baseline 4 for zero params is appropriate.

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?

The description states a specific verb ('List') and resource ('available Flux resources and capabilities'), and explicitly positions itself as the entry point for all other tools. This clearly distinguishes it from siblings like describe_resource and query_records, which operate on specific resources or records.

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?

The description explicitly says 'Start here' and explains that every other tool takes a resource_id from this list, and that a resource's capabilities say which tools it will accept. This gives the agent a clear when-to-use directive and implicitly tells it not to use this tool for anything else.

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

get_recordA
Read-onlyIdempotent
Inspect

Fetch one record by id for a resource_id, whole and untruncated. Use it when the id is already known; where the resource lists get_many among its discover_resources capabilities, search_records or query_records finds one first.

ParametersJSON Schema
NameRequiredDescriptionDefault
localesNoLocale codes (`en`, `fr`, ...) to keep in localized fields. Omit it to get every locale the record carries, which is the right default unless one language was asked for. The codes are the keys of a localized field in any record of this collection; a code the environment does not use is not an error, it simply matches nothing.
parentsNoParent placeholders for nested resource_id templates.
populateNoReference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key, which costs one call instead of two. Populated records are never shortened, whatever the text limit is.
record_idYesDocument key (_sys.key) to retrieve.
resource_idYesResource identifier from discover_resources.

Output Schema

ParametersJSON Schema
NameRequiredDescription
foundYes
recordNoNull when `found` is false. Never shortened, whatever the collection's text limit is.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond those annotations: the returned record is 'whole and untruncated', and populated references are never shortened. Together with the output schema, this gives the agent a clear expectation of what the call returns without overclaiming side effects.

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?

Two sentences with no filler: the first states what the tool does and the second gives the routing condition. The most important usage constraint is front-loaded, and every clause earns its place.

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 rich annotations, complete parameter schema descriptions, and an output schema, the description covers the remaining contextual gap: when to choose this tool and the completeness guarantee for returned records. Nothing essential is missing for an agent to invoke it correctly.

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 itself fully documents record_id, resource_id, locales, parents, and populate. The description adds some semantic emphasis (whole and untruncated, id-based retrieval) but does not need to repeat parameter details. A baseline of 3 is appropriate because the schema carries the parameter documentation burden.

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?

The description names a specific verb and resource ('Fetch one record by id for a resource_id'), adds a concrete behavioral guarantee ('whole and untruncated'), and distinguishes itself from siblings by pointing to search_records/query_records when the id is not known. This clearly separates it from the other read and write tools in the sibling list.

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?

It explicitly states when to use this tool ('Use it when the id is already known') and names the alternatives ('search_records or query_records finds one first') for the case where discovery lists get_many. This is direct, actionable routing guidance rather than a vague description.

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

query_recordsA
Read-onlyIdempotent
Inspect

List records by filters/sort/cursor for a resource_id. Use it when the selection is expressible as field conditions; when the request is in the user's own words, search_records ranks by meaning instead. Long text fields may be shortened in results; a shortened record carries _sys.truncated. Where the resource lists get_one among its discover_resources capabilities, call get_record with that record's id for the full document. Returns 5 records unless limit says otherwise — enough to find a document and then fetch it. When the task is to enumerate or count, raise limit (up to 100) instead of paging through small pages: every page is resent on every later turn, so many small pages cost far more than one large one.

ParametersJSON Schema
NameRequiredDescriptionDefault
sortNoField names to order by, most significant first. Prefix a name with `-` for descending, so `-_sys.created_at` is newest first. `_sys` fields are sortable as well as schema fields; describe_resource lists the schema ones.
limitNoRecords per call. Defaults to 5, which is enough to pick a hit and fetch it in full with get_record. Raise it (up to 100) when the task is to enumerate or count rather than to find.
cursorNoPass back `page.next_cursor` from a previous response to get the following page. Reach for it only when a page really has to be continued: raising `limit` costs one call where paging costs one per page, and every page already fetched is re-sent on every later turn.
filtersNoField conditions, all of which must hold. `field` is a field path from the collection's describe_resource schema, `op` defaults to `eq`, and `value` follows the operator: a list for `in`/`not_in`, a two-element list for `between`, a single value otherwise.
localesNoLocale codes (`en`, `fr`, ...) to keep in localized fields. Omit it to get every locale the record carries, which is the right default unless one language was asked for. The codes are the keys of a localized field in any record of this collection; a code the environment does not use is not an error, it simply matches nothing.
parentsNoParent placeholders for nested resource_id templates.
populateNoReference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key. Prefer it whenever a list result carries references the task needs: resolving them afterwards costs one call per record, and every earlier result is re-sent on every later turn, so ten resolved by hand cost far more than one populated call. Populated records obey the same text limit as the rest of this response; call get_record on a key for the unshortened record.
resource_idYesResource identifier from discover_resources.

Output Schema

ParametersJSON Schema
NameRequiredDescription
pageYes
itemsYesThe matching records, at most `limit` of them.
truncationNoPresent when a text limit is in force for this collection.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable behavior beyond that: long text fields may be truncated with a `_sys.truncated` flag, and it explains the cost model where every page is re-sent on later turns. It does not cover all possible edge cases (e.g., empty results), but it is substantially transparent.

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?

The description is long but every sentence serves a purpose. It front-loads the core purpose, then usage guidance, then behavioral and performance notes. It is dense and well-organized, not verbose, though slightly longer than strictly necessary.

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?

For a tool with 8 parameters, nested objects, and several sibling tools, this description is exceptionally complete. It covers selection criteria, result truncation, paging costs, reference population, and the relationship to get_record and search_records. With an output schema present, nothing essential is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The main description adds strategic guidance on `limit` (raise for enumeration) and `cursor` (avoid paging because of re-send costs), supplementing the already detailed schema descriptions. This adds meaning beyond the schema, though not for every parameter individually.

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?

The description opens with a precise verb+resource: 'List records by filters/sort/cursor for a resource_id.' It also distinguishes itself from sibling tools, explicitly noting search_records for natural-language queries and get_record for full documents, so an agent can immediately tell when this tool is the right choice.

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?

It provides explicit when-to-use guidance: use when selection is expressible as field conditions, and use search_records when the request is in the user's own words. It also directs toward get_record for full documents and advises raising `limit` for enumeration/counting rather than paging. This is clear routing with no ambiguity.

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

search_recordsA
Read-onlyIdempotent
Inspect

Search records for a resource_id; search_type decides how the query is matched and defaults to hybrid. Use it when the request is in the user's own words; when the selection is an exact field condition, query_records filters without ranking. Long text fields may be shortened in results; a shortened record carries _sys.truncated. Where the resource lists get_one among its discover_resources capabilities, call get_record with that record's id for the full document. Returns 5 records unless limit says otherwise — enough to choose among hits and then fetch one. When the task is to enumerate or count, raise limit (up to 100) instead of paging through small pages: every page is resent on every later turn, so many small pages cost far more than one large one.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoRecords per call. Defaults to 5, which is enough to pick a hit and fetch it in full with get_record. Raise it (up to 100) when the task is to enumerate or count rather than to find.
queryYesThe text to search for. Whether it is matched by keyword, by meaning, or by both is decided by `search_type`.
cursorNoPass back `page.next_cursor` from a previous response to get the following page. Reach for it only when a page really has to be continued: raising `limit` costs one call where paging costs one per page, and every page already fetched is re-sent on every later turn.
filtersNoField conditions, all of which must hold. `field` is a field path from the collection's describe_resource schema, `op` defaults to `eq`, and `value` follows the operator: a list for `in`/`not_in`, a two-element list for `between`, a single value otherwise.
localesNoLocale codes (`en`, `fr`, ...) to keep in localized fields. Omit it to get every locale the record carries, which is the right default unless one language was asked for. The codes are the keys of a localized field in any record of this collection; a code the environment does not use is not an error, it simply matches nothing.
parentsNoParent placeholders for nested resource_id templates.
populateNoReference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key. Prefer it whenever a list result carries references the task needs: resolving them afterwards costs one call per record, and every earlier result is re-sent on every later turn, so ten resolved by hand cost far more than one populated call. Populated records obey the same text limit as the rest of this response; call get_record on a key for the unshortened record.
resource_idYesResource identifier from discover_resources.
search_typeNoHow `query` is matched. `hybrid` (the default) ranks a union of keyword and meaning matches and is the right choice when in doubt. `text` matches keywords only — use it for identifiers, codes, names and exact phrases. `semantic` matches meaning only, so it can return records that share no word with the query, and it returns nothing at all on a collection with no embeddings. `vector_boosted` keeps `text`'s guarantee that every result really contains the query terms and only reorders them, lifting the closest few by meaning to the top; the rest keep the collection's default order and report `_sys.relevance` 0.hybrid

Output Schema

ParametersJSON Schema
NameRequiredDescription
pageYes
itemsYesThe matching records, ranked, at most `limit` of them.
truncationNoPresent when a text limit is in force for this collection.
execution_infoNoWhich search mode actually ran, which can differ from `search_type` when a mode is unavailable.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: long text fields may be shortened with `_sys.truncated`, results default to 5, every page is re-sent on later turns, and vector_boosted reports `_sys.relevance` 0 for non-boosted results. This is rich, non-obvious behavior that an agent could not infer from annotations or schema alone.

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?

The description is dense but well-organized, with the core purpose and sibling differentiation front-loaded. Every sentence earns its place, and the cost-model guidance is valuable. It is longer than strictly necessary, but the length is justified by the tool's complexity (9 parameters, 4 search types, pagination, truncation, population). A slightly tighter structure would earn a 5.

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 tool's complexity, the description covers all the critical operational aspects: when to use it, how search_type behaves, truncation, pagination costs, limit guidance, and the relationship to get_record. The output schema exists, so return values don't need to be spelled out. The only minor gap is that it doesn't explicitly mention the `filters` parameter's interaction with ranking, but the schema covers filters well and the description's focus on search_type is sufficient.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema for several parameters: it explains the cost model behind limit and cursor, clarifies that populate avoids per-record resolution costs, and gives nuanced guidance on search_type (e.g., semantic returns nothing on collections without embeddings, vector_boosted preserves text's guarantee). It doesn't add much for resource_id or parents, but the schema already covers those adequately.

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?

The description opens with a specific verb and resource ('Search records for a resource_id') and immediately distinguishes itself from query_records by naming the sibling and the exact condition that selects it ('when the selection is an exact field condition, query_records filters without ranking'). It also explains the search_type semantics, so an agent can tell this tool apart from its siblings without opening the 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?

The description gives explicit when-to-use guidance: use it when the request is in the user's own words, and use query_records for exact field conditions. It also provides concrete operational guidance: raise limit for enumeration/counting, use get_record for full documents, and prefer populate over resolving references. This is exactly the kind of routing and decision support an agent needs.

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

update_recordA
Destructive
Inspect

Replace a record's document with a new published revision (full-document replace, not a partial patch). data must match the collection schema (see describe_resource). Requires the UPDATE permission on this API.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesFull replacement document matching the schema.
parentsNoParent placeholders for nested collection resource_ids.
record_idYesresource_key of the record to replace.
collectionYesCollection resource_id from discover_resources.
expected_revisionNoOptional. Apply the write only if the record's current revision is still this one -- pass the `_sys.revision` value from the record you read. Prevents silently overwriting another writer's update; returns precondition_failed if the record moved on.

TDQS

A4/5.0
Behavior4/5

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

Annotations already mark this as destructive and not read-only, and the description builds on that by stating the entire document is replaced, not patched, and that a new published revision is created. It also discloses permission needs)Skip, which the annotations do not include.

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?

Two sentences carry maximum signal: the first defines the operation and its boundary, the second adds schema and permission context. No filler, no repetition of schema content, and key behavior is front-loaded.

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?

For a destructive full-replace operation with no output schema, the description is nearly complete. It states the semantic, the permission requirement, and the schema constraint. It does not describe the exact response or failure modes, but the annotations and full parameter schemas cover the invocation essentials.

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 explains all five parameters thoroughly. The description adds the requirement that `data` must match the collection schema and referencesthe describe_resource tool, but it does not need to duplicate parameter-level details.

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?

The description names a specific verb ('Replace'), resource ('a record's document'), and action type ('full-document replace, not a partial patch'). It clearly distinguishes the tool from creation or reading, and the 'new published revision' detail adds precision.

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 makes the use case clear: replace a full record, not patch it. It mentions a prerequisite (UPDATE permission) and a pointer to describe_resource for schema validation. However, it does not explicitly compare against siblings like create_record or get_record or provide a when-not-to-use condition.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • Changeddescribe_resource1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "actions": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "alias": {
+      "type": "string"
+    },
+    "content_type": {
+      "type": "string"
+    },
+    "description": {
+      "type": "string"
+    },
+    "json_schema": {
+      "additionalProperties": true,
+      "description": "JSON Schema of the record body. Reference fields appear as plain strings; nothing here marks them as references.",
+      "type": "object"
+    },
+    "name": {
+      "type": "string"
+    },
+    "non_searchable_fields": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "path": {
+      "type": "string"
+    },
+    "required_parents": {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "resource_id": {
+      "type": "string"
+    },
+    "schema_key": {
+      "type": "string"
+    },
+    "schema_version_key": {
+      "type": "string"
+    },
+    "searchable_fields": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "json_schema",
+    "resource_id"
+  ],
+  "type": "object"
+}
    • Changeddiscover_resources1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "api": {
+      "description": "Prefix of the Flux API these resources are reached through.",
+      "type": "string"
+    },
+    "resources": {
+      "items": {
+        "properties": {
+          "capabilities": {
+            "description": "Which reads this resource accepts: get_many, get_one, search.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "description": {
+            "description": "The only free text about what a collection holds. Empty when the owner set none.",
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "path_template": {
+            "type": "string"
+          },
+          "required_parents": {
+            "description": "Placeholders the `parents` argument must fill for a nested resource.",
+            "items": {
+              "properties": {
+                "name": {
+                  "type": "string"
+                },
+                "required": {
+                  "type": "boolean"
+                },
+                "resource": {
+                  "type": "string"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "resource_id": {
+            "description": "Pass verbatim as `resource_id` to every other tool.",
+            "type": "string"
+          },
+          "schema_ref": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "writable": {
+            "description": "Empty unless the key carries write grants for this resource.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "resource_id",
+          "capabilities"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "usage_rules": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "api",
+    "resources"
+  ],
+  "type": "object"
+}
    • Changedget_record1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "found": {
+      "type": "boolean"
+    },
+    "record": {
+      "description": "Null when `found` is false. Never shortened, whatever the collection's text limit is.",
+      "properties": {
+        "_sys": {
+          "properties": {
+            "created_at": {
+              "format": "date-time",
+              "type": "string"
+            },
+            "folder": {
+              "type": "string"
+            },
+            "key": {
+              "type": "string"
+            },
+            "relevance": {
+              "type": [
+                "number",
+                "null"
+              ]
+            },
+            "revision": {
+              "type": "string"
+            },
+            "truncated": {
+              "description": "Present only when this record had text shortened. One entry per field that was cut.",
+              "items": {
+                "properties": {
+                  "field": {
+                    "description": "Path to the shortened field, `author.bio` for one reached through populate.",
+                    "type": "string"
+                  },
+                  "locale": {
+                    "type": [
+                      "string",
+                      "null"
+                    ]
+                  },
+                  "original_length": {
+                    "type": "integer"
+                  }
+                },
+                "required": [
+                  "field",
+                  "original_length"
+                ],
+                "type": "object"
+              },
+              "type": "array"
+            },
+            "updated_at": {
+              "format": "date-time",
+              "type": "string"
+            }
+          },
+          "required": [
+            "key"
+          ],
+          "type": "object"
+        },
+        "data": {
+          "additionalProperties": true,
+          "description": "The record itself, shaped by the collection schema that describe_resource returns.",
+          "type": "object"
+        },
+        "id": {
+          "description": "Document key. Pass it to get_record as `record_id`.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "data",
+        "_sys"
+      ],
+      "type": [
+        "object",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "found"
+  ],
+  "type": "object"
+}
    • Changedsearch_records1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "execution_info": {
+      "description": "Which search mode actually ran, which can differ from `search_type` when a mode is unavailable.",
+      "properties": {
+        "applied_search_type": {
+          "type": "string"
+        },
+        "search_mode": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "items": {
+      "description": "The matching records, ranked, at most `limit` of them.",
+      "items": {
+        "properties": {
+          "_sys": {
+            "properties": {
+              "created_at": {
+                "format": "date-time",
+                "type": "string"
+              },
+              "folder": {
+                "type": "string"
+              },
+              "key": {
+                "type": "string"
+              },
+              "relevance": {
+                "type": [
+                  "number",
+                  "null"
+                ]
+              },
+              "revision": {
+                "type": "string"
+              },
+              "truncated": {
+                "description": "Present only when this record had text shortened. One entry per field that was cut.",
+                "items": {
+                  "properties": {
+                    "field": {
+                      "description": "Path to the shortened field, `author.bio` for one reached through populate.",
+                      "type": "string"
+                    },
+                    "locale": {
+                      "type": [
+                        "string",
+                        "null"
+                      ]
+                    },
+                    "original_length": {
+                      "type": "integer"
+                    }
+                  },
+                  "required": [
+                    "field",
+                    "original_length"
+                  ],
+                  "type": "object"
+                },
+                "type": "array"
+              },
+              "updated_at": {
+                "format": "date-time",
+                "type": "string"
+              }
+            },
+            "required": [
+              "key"
+            ],
+            "type": "object"
+          },
+          "data": {
+            "additionalProperties": true,
+            "description": "The record itself, shaped by the collection schema that describe_resource returns.",
+            "type": "object"
+          },
+          "id": {
+            "description": "Document key. Pass it to get_record as `record_id`.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "data",
+          "_sys"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "page": {
+      "properties": {
+        "has_more": {
+          "type": "boolean"
+        },
+        "limit": {
+          "type": "integer"
+        },
+        "next_cursor": {
+          "description": "Pass back as `cursor` to continue. Null when there is no further page.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "previous_cursor": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "returned": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "has_more",
+        "returned",
+        "limit"
+      ],
+      "type": "object"
+    },
+    "truncation": {
+      "description": "Present when a text limit is in force for this collection.",
+      "properties": {
+        "applied": {
+          "type": "boolean"
+        },
+        "max_text_chars": {
+          "type": "integer"
+        },
+        "note": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "items",
+    "page"
+  ],
+  "type": "object"
+}
  2. 1 tool update
    • Changedquery_records1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "items": {
+      "description": "The matching records, at most `limit` of them.",
+      "items": {
+        "properties": {
+          "_sys": {
+            "properties": {
+              "created_at": {
+                "format": "date-time",
+                "type": "string"
+              },
+              "folder": {
+                "type": "string"
+              },
+              "key": {
+                "type": "string"
+              },
+              "relevance": {
+                "type": [
+                  "number",
+                  "null"
+                ]
+              },
+              "revision": {
+                "type": "string"
+              },
+              "truncated": {
+                "description": "Present only when this record had text shortened. One entry per field that was cut.",
+                "items": {
+                  "properties": {
+                    "field": {
+                      "description": "Path to the shortened field, `author.bio` for one reached through populate.",
+                      "type": "string"
+                    },
+                    "locale": {
+                      "type": [
+                        "string",
+                        "null"
+                      ]
+                    },
+                    "original_length": {
+                      "type": "integer"
+                    }
+                  },
+                  "required": [
+                    "field",
+                    "original_length"
+                  ],
+                  "type": "object"
+                },
+                "type": "array"
+              },
+              "updated_at": {
+                "format": "date-time",
+                "type": "string"
+              }
+            },
+            "required": [
+              "key"
+            ],
+            "type": "object"
+          },
+          "data": {
+            "additionalProperties": true,
+            "description": "The record itself, shaped by the collection schema that describe_resource returns.",
+            "type": "object"
+          },
+          "id": {
+            "description": "Document key. Pass it to get_record as `record_id`.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "data",
+          "_sys"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "page": {
+      "properties": {
+        "has_more": {
+          "type": "boolean"
+        },
+        "limit": {
+          "type": "integer"
+        },
+        "next_cursor": {
+          "description": "Pass back as `cursor` to continue. Null when there is no further page.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "previous_cursor": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "returned": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "has_more",
+        "returned",
+        "limit"
+      ],
+      "type": "object"
+    },
+    "truncation": {
+      "description": "Present when a text limit is in force for this collection.",
+      "properties": {
+        "applied": {
+          "type": "boolean"
+        },
+        "max_text_chars": {
+          "type": "integer"
+        },
+        "note": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "items",
+    "page"
+  ],
+  "type": "object"
+}
  3. 2 tool updates
    • Changedquery_records2 fields changed
      • addedInput schema / properties / cursor / description
        Added value: +"Pass back `page.next_cursor` from a previous response to get the following page. Reach for it only when a page really has to be continued: raising `limit` costs one call where paging costs one per page, and every page already fetched is re-sent on every later turn."
      • addedInput schema / properties / sort / description
        Added value: +"Field names to order by, most significant first. Prefix a name with `-` for descending, so `-_sys.created_at` is newest first. `_sys` fields are sortable as well as schema fields; describe_resource lists the schema ones."
    • Changedsearch_records1 field changed
      • addedInput schema / properties / cursor / description
        Added value: +"Pass back `page.next_cursor` from a previous response to get the following page. Reach for it only when a page really has to be continued: raising `limit` costs one call where paging costs one per page, and every page already fetched is re-sent on every later turn."
  4. 2 tool updates
    • Changedquery_records2 fields changed
      • removedInput schema / properties / cursor / description
        Removed value: -"Pass back `page.next_cursor` from a previous response to get the following page. Reach for it only when a page really has to be continued: raising `limit` costs one call where paging costs one per page, and every page already fetched is re-sent on every later turn."
      • removedInput schema / properties / sort / description
        Removed value: -"Field names to order by, most significant first. Prefix a name with `-` for descending, so `-_sys.created_at` is newest first. `_sys` fields are sortable as well as schema fields; describe_resource lists the schema ones."
    • Changedsearch_records1 field changed
      • removedInput schema / properties / cursor / description
        Removed value: -"Pass back `page.next_cursor` from a previous response to get the following page. Reach for it only when a page really has to be continued: raising `limit` costs one call where paging costs one per page, and every page already fetched is re-sent on every later turn."
  5. 2 tool updates
    • Changedquery_records3 fields changed
      • addedInput schema / properties / cursor / description
        Added value: +"Pass back `page.next_cursor` from a previous response to get the following page. Reach for it only when a page really has to be continued: raising `limit` costs one call where paging costs one per page, and every page already fetched is re-sent on every later turn."
      • changedInput schema / properties / populate / description
        Previous value: -"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key, which costs one call instead of two. Populated records obey the same text limit as the rest of this response; call get_record on a key for the unshortened record."New value: +"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key. Prefer it whenever a list result carries references the task needs: resolving them afterwards costs one call per record, and every earlier result is re-sent on every later turn, so ten resolved by hand cost far more than one populated call. Populated records obey the same text limit as the rest of this response; call get_record on a key for the unshortened record."
      • addedInput schema / properties / sort / description
        Added value: +"Field names to order by, most significant first. Prefix a name with `-` for descending, so `-_sys.created_at` is newest first. `_sys` fields are sortable as well as schema fields; describe_resource lists the schema ones."
    • Changedsearch_records2 fields changed
      • addedInput schema / properties / cursor / description
        Added value: +"Pass back `page.next_cursor` from a previous response to get the following page. Reach for it only when a page really has to be continued: raising `limit` costs one call where paging costs one per page, and every page already fetched is re-sent on every later turn."
      • changedInput schema / properties / populate / description
        Previous value: -"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key, which costs one call instead of two. Populated records obey the same text limit as the rest of this response; call get_record on a key for the unshortened record."New value: +"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key. Prefer it whenever a list result carries references the task needs: resolving them afterwards costs one call per record, and every earlier result is re-sent on every later turn, so ten resolved by hand cost far more than one populated call. Populated records obey the same text limit as the rest of this response; call get_record on a key for the unshortened record."
  6. 2 tool updates
    • Changedquery_records1 field changed
      • changedInput schema / properties / populate / description
        Previous value: -"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key, which costs one call instead of two. Populated records are never shortened, whatever the text limit is."New value: +"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key, which costs one call instead of two. Populated records obey the same text limit as the rest of this response; call get_record on a key for the unshortened record."
    • Changedsearch_records1 field changed
      • changedInput schema / properties / populate / description
        Previous value: -"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key, which costs one call instead of two. Populated records are never shortened, whatever the text limit is."New value: +"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key, which costs one call instead of two. Populated records obey the same text limit as the rest of this response; call get_record on a key for the unshortened record."
  7. 3 tool updates
    • Changedget_record1 field changed
      • addedInput schema / properties / populate / description
        Added value: +"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key, which costs one call instead of two. Populated records are never shortened, whatever the text limit is."
    • Changedquery_records1 field changed
      • addedInput schema / properties / populate / description
        Added value: +"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key, which costs one call instead of two. Populated records are never shortened, whatever the text limit is."
    • Changedsearch_records1 field changed
      • addedInput schema / properties / populate / description
        Added value: +"Reference and relation fields come back as opaque record keys. Name those fields here and the records they point at are fetched and grafted in place of the key, which costs one call instead of two. Populated records are never shortened, whatever the text limit is."
  8. 3 tool updates
    • Changedget_record1 field changed
      • addedInput schema / properties / locales / description
        Added value: +"Locale codes (`en`, `fr`, ...) to keep in localized fields. Omit it to get every locale the record carries, which is the right default unless one language was asked for. The codes are the keys of a localized field in any record of this collection; a code the environment does not use is not an error, it simply matches nothing."
    • Changedquery_records2 fields changed
      • addedInput schema / properties / filters / description
        Added value: +"Field conditions, all of which must hold. `field` is a field path from the collection's describe_resource schema, `op` defaults to `eq`, and `value` follows the operator: a list for `in`/`not_in`, a two-element list for `between`, a single value otherwise."
      • addedInput schema / properties / locales / description
        Added value: +"Locale codes (`en`, `fr`, ...) to keep in localized fields. Omit it to get every locale the record carries, which is the right default unless one language was asked for. The codes are the keys of a localized field in any record of this collection; a code the environment does not use is not an error, it simply matches nothing."
    • Changedsearch_records5 fields changed
      • addedInput schema / properties / filters / description
        Added value: +"Field conditions, all of which must hold. `field` is a field path from the collection's describe_resource schema, `op` defaults to `eq`, and `value` follows the operator: a list for `in`/`not_in`, a two-element list for `between`, a single value otherwise."
      • addedInput schema / properties / locales / description
        Added value: +"Locale codes (`en`, `fr`, ...) to keep in localized fields. Omit it to get every locale the record carries, which is the right default unless one language was asked for. The codes are the keys of a localized field in any record of this collection; a code the environment does not use is not an error, it simply matches nothing."
      • addedInput schema / properties / query / description
        Added value: +"The text to search for. Whether it is matched by keyword, by meaning, or by both is decided by `search_type`."
      • addedInput schema / properties / search_type / default
        Added value: +"hybrid"
      • addedInput schema / properties / search_type / description
        Added value: +"How `query` is matched. `hybrid` (the default) ranks a union of keyword and meaning matches and is the right choice when in doubt. `text` matches keywords only — use it for identifiers, codes, names and exact phrases. `semantic` matches meaning only, so it can return records that share no word with the query, and it returns nothing at all on a collection with no embeddings. `vector_boosted` keeps `text`'s guarantee that every result really contains the query terms and only reorders them, lifting the closest few by meaning to the top; the rest keep the collection's default order and report `_sys.relevance` 0."
  9. 2 tool updates
    • Addedcreate_record
    • Addedupdate_record
  10. 5 tool updates
    • First observeddescribe_resource
    • First observeddiscover_resources
    • First observedget_record
    • First observedquery_records
    • First observedsearch_records

Publisher details

Operator
FoxNose · Publisher source
Operator website
https://foxnose.net · Publisher source
Vendor relationship
First-party · Publisher source
Documentation
https://foxnose.net/docs/mcp · Publisher source
Trust center
https://foxnose.net/security · Publisher source
Restrictions
No paid plan, admin approval, custom OAuth app or regional limit is required. A free tier key works. Two setup details worth knowing. If your API key can read more than one Flux API, pass the API prefix in the x-foxnose-prefix header, otherwise the connection fails with prefix_required and lists the prefixes the key can reach. The write tools (create_record, update_record) appear in tools/list only when the key grants create and update on the selected API, so a read-only key sees five tools instead of seven. · Publisher source

Related MCP Connectors

Related MCP Servers

  • memo-mcp

    kKEo
    F
    license
    Not graded
    quality
    A
    maintenance
    Enables agents to store documents and atomic facts with provenance in a local SQLite knowledge base, then search them through fused keyword, exact, semantic, entity, graph and fact retrieval arms that return one ranked list where every result carries its address, trust level and a reason for its rank. A read-only terminal and loopback web view let humans inspect the same searches, timelines, entity neighbourhoods and agent-written pages without being able to alter the knowledge base.
    -

  • MCP Elasticsearch Demo

    dev-com2020
    F
    license
    A
    quality
    C
    maintenance
    Enables LLM agents to search and retrieve a hybrid knowledge base of manuals, videos, PDFs, DOCX files and images through tools for hybrid BM25-plus-vector search with facet and tag filters, full document retrieval, semantically similar document lookup, and timestamped video transcript segments. It ships with an in-memory backend for instant local use and an identical Elasticsearch backend for production deployment over stdio or authenticated HTTP.
    5
    -

  • AI Knowledge Base MCP Server

    Alpha-W0lf
    A
    license
    B
    quality
    A
    maintenance
    Provides read-only hybrid RAG search and discovery over a local-first AI knowledge corpus, enabling semantic and keyword search, browse, digest, and status tools.
    4
    PolyForm Noncommercial 1.0.0

  • windex MCP server

    stevemurr
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables hybrid search (dense + sparse) over self-hosted indexes of continuously ingested public datasets (news, GitHub, Wikipedia, arXiv, small web, devdocs, Hacker News) using your own embedding model, served via the Model Context Protocol.
    3
    -
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