Skip to main content
Glama
Monyeah777

NinFenz Content Gate

by Monyeah777
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Fetch asset content

asset_read
Read-onlyIdempotent

Read a content asset by exact key and return its package, path, and full text. Use only keys from asset_list; add a package to limit the search.

Instructions

Read asset files for a key, returning package, path, and text.

Use only a key from asset_list; for enumeration use asset_list, for other resources module_read or pipeline_read.

The key is exact uppercase, never glob, regex, package, path, or prose. The package is an exact directory; it narrows files but never key matching.

Tokens come from each file's name or first 6000 characters; lowercase/partial keys fail. Full text is returned; no truncation.

Without a package, all community assets and 05_资产库 are searched. A package limits the scan to one directory with no fallback. Multiple matches may be returned. No match is an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesExact, case-sensitive asset key (for example EMOTION_WHEEL, JOB, or TECH_RULES).
packageNoOptional community package name; omit to search all community assets and 05_资产库.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyYesRequested asset key.
matchesYesMatching files, one entry per declaring asset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.11.2
    • removedOutput schema / properties / found
      Removed value: -{
-  "description": "True when at least one asset file matched.",
-  "type": "boolean"
-}
    • changedOutput schema / required
      Previous value: -[
-  "found",
-  "key",
-  "matches"
-]New value: +[
+  "key",
+  "matches"
+]
  2. Added

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: it discloses the default search scope (all community assets plus 05_资产库), that a package limits the scan to one directory with no fallback, that multiple matches may be returned, that no match is an error, and that full untruncated text is returned. Annotations only cover safety; the description carries the substantive behavior.

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 purpose, then constraints, then scope — good ordering with no filler sentences. The telegraphic style ('Tokens come from each file's name or first 6000 characters') is dense enough that a first-time reader may need a re-read, costing some clarity.

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 an output schema present, return values need not be explained, and the description covers everything else an agent needs: valid input form, failure conditions, search scope, and multiplicity of results. Nothing material is missing for a two-parameter read tool.

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?

Although schema coverage is 100%, the description adds real semantics the schema lacks: keys are exact uppercase and never glob/regex/package/path/prose, lowercase or partial keys fail, and package narrows files but never key matching. It also explains that omitting package searches all community assets and 05_资产库.

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 — 'Read asset files for a key' — and even names the return shape (package, path, text). It explicitly distinguishes itself from asset_list, module_read, and pipeline_read, so an agent can route without opening sibling schemas.

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 ('Use only a key from asset_list') and when-to-use-something-else ('for enumeration use asset_list, for other resources module_read or pipeline_read'). The alternative routing is unambiguous.

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

Deploy Server

Other Tools