Rights-aware censorship, China-economic status, and tamper-evident AI evaluation tools.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 6 of 6 tools scored.
get_newsroom 和 get_signal 之间的边界不够清晰，尤其是 economy 视图与中国经济信号、machine-analysis 视图与 eval 信号在功能上有所重叠；query_economic_observations 也与中国经济读取工具有部分交叠。不过每个工具的详细描述都试图说明其特定用途，且 gfw_reading、whats_happening 与 get_signal 的差异已被明确点出，因此并非完全无法区分。
大多数工具遵循动词_名词模式（get_newsroom, get_signal, list_signals, query_economic_observations），但 gfw_reading 是名词+动名词结构，whats_happening 是口语化问句，打破了统一模式。整体仍保持小写蛇形且可读，属于混合惯例但可接受的级别。
6 个工具对于一个横跨审查、中国经济和 AI 模型评估三个应用的观察站来说非常合适：既有足够的功能入口，又不过度碎片化。每个工具都对应一个明确的职责面，且内部承载多个信号/视图，工具数量与领域复杂度匹配良好。
工具覆盖了信号发现（list_signals）、单信号读取（get_signal）、组合视图（gfw_reading）、跨信号判断（whats_happening）、报道/编辑表面（get_newsroom）以及经济权限状态（query_economic_observations），基本没有明显死路。次要缺口如缺少中国经济非受限数据的直接读取或信号历史访问，但这些受制于设计策略或可通过现有工具间接获得。
get_newsroomEvidence and reporting desksARead one evidence-first reporting surface without scraping a page or guessing a filename. Views: 'newsroom' for prioritized deterministic stories, 'wire' for normalized source dossiers, 'economy' for the currently restricted China economic pulse, 'machine-analysis' for the currently restricted AnalysisReports and AbstentionReports, 'investigations' for review-gated research leads, 'editorial-readiness' for publication gates, and 'interconnection' for named-key fat-object joins on China situation events (topic-surface-only, never wire corroboration). The economy, machine-analysis and interconnection views are metadata-only until a lineage-filtered rebuild removes denied derivatives. Availability never implies publication readiness: statuses, gates, counterevidence, limitations and right-to-reply state stay attached.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | newsroom | |
| limit | No | ||
| status | No | optional exact status filter for story/case views | |
| priority | No | optional exact priority filter for the newsroom view |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds substantial behavioral context: which views are restricted, which are metadata-only pending a lineage-filtered rebuild, and that availability never implies publication readiness. This goes well beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear action and then organizes the views in a scannable list. It is dense and includes relevant caveats, though the long semicolon-run style and specialized phrasing could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, annotations, and lack of output schema, the description covers view selection, restricted access, metadata-only behavior, and status attachment. It does not explicitly describe the return shape, but this is a read-only, no-output-schema tool and the key operational constraints are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers status and priority with descriptions, and the tool description adds meaning to the undocumented 'view' parameter by explaining each enum value. The 'limit' parameter is not described in prose, but its schema-level minimum/maximum/default are explicit, so the description compensates adequately for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and names the resource ('evidence-first reporting surface'), then enumerates all seven views with their distinct meanings. It does not explicitly differentiate this from siblings like get_signal or whats_happening, but the view list makes the tool's scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by explaining what each view is for ('newsroom' for prioritized deterministic stories, 'wire' for normalized source dossiers, etc.) and flags restricted/metadata-only views. It does not name alternative tools or provide explicit when/when-not comparisons, but the within-tool view guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_signalOne signal's full readingARead one named signal. Permitted signals return their bounded latest payload; China-economic signals in the denied lineage closure return explicit restricted/unavailable rights metadata and no values. Call list_signals first to discover valid names. Use this for the AI-model-evaluation side too: 'eval-registry' returns the pre-registered, hash-chained eval ledger with its verified flag and Merkle root, 'gfi-transcripts' returns a bounded view of the complete GFI v2 response matrix, and 'refusal-drift' returns the current frontier-model refusal reading on the frozen benign probe set; read 'eval-assurance' before turning either into a validity claim, and 'eval-journal' for the evidence-bound explanation and source receipts, or 'eval-findings' for the current deterministic article edition. Distinct from gfw_reading, which merges the two Great Firewall layers into one combined view.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | signal name from list_signals, e.g. 'ooni-gfw', 'eval-registry', 'eval-assurance', 'eval-journal', 'eval-findings', 'gfi-transcripts' or 'refusal-drift' | |
| max_rows | No | cap on long row arrays (dataset, ranked, samples). Default 25 keeps a call small enough not to stall a tool loop; the generative-firewall-index dataset is 132 rows. Any cap applied is reported in the response with the true total, never silently. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description discloses that denied-lineage China signals return rights metadata instead of values, and that max_rows caps are reported with the true total rather than silently. This adds concrete behavioral context not present in the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then expands. The long enumeration of eval signals is dense but each item adds specific value, so it earns its space. It is not succinct, but the complexity justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description covers return behavior for permitted signals, denied signals, and each eval signal, plus the max_rows cap reporting and prerequisite list_signals call. An agent has everything needed to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds meaningful semantics: it explains that max_rows caps are reported explicitly and that list_signals should be called first to get valid names. This goes beyond the schema's simple field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Read one named signal,' a specific verb+resource statement. It then clarifies the two output categories (bounded payload vs. restricted rights metadata) and explicitly distinguishes from gfw_reading, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It instructs to call list_signals first to discover valid names, and explicitly names gfw_reading as the alternative for a combined view. It also gives per-signal usage notes (e.g., read 'eval-assurance' before making validity claims), covering when and when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gfw_readingGreat Firewall: both layersARead the Great Firewall's current state at both layers in one call: live network blocking measured inside China via OONI (website, messenger and circumvention-tool reachability) joined with model-layer censorship from the Generative Firewall Index over Chinese LLMs. Takes no arguments. A combined convenience view — for one layer's full raw payload use get_signal with 'ooni-gfw' or 'generative-firewall-index'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds context about the combined data (live network blocking and model-layer censorship), which is useful but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and every sentence adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with rich annotations, the description adequately explains the return data and alternatives. Minor gap: no mention of caching or staleness, but not critical for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters. The description confirms this with 'Takes no arguments'. Per guidelines, 0 params baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool reads the Great Firewall's state at both layers, specifying OONI and Generative Firewall Index. It distinguishes from siblings by noting that get_signal should be used for one layer's full raw payload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly advises when to use this tool (convenience view) and when to use the alternative (get_signal with specific arguments). It also notes that no arguments are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_signalsList published signalsAList every published signal Palimpsest exposes across its three applications: name, one-line description and source URL for each. Censorship and information control — OONI Great Firewall probes, Censored Planet, IODA outages, circumvention demand, takedown and redaction pressure, and the board's own verdict. China economics — explicit metadata-only rights status for affected observations, pulse, forecast and derivative surfaces; no denied values are returned. AI model evaluation — the tamper-evident, pre-registered eval registry (hash-chained and Merkle-rooted), its claim-by-claim assurance ceiling, evidence-bound Eval Journal, deterministic live findings, and frontier-model refusal drift, alongside the Generative Firewall Index over a named China-focused panel. Takes no arguments. Call this first to discover signal names, then get_signal for one full reading.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds meaningful output behavior: the exact fields (name, one-line description, source URL) and the guarantee that 'no denied values are returned.' It does not contradict annotations and enhances the agent's expectation of what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than a simple listing, but each section (the three application categories) provides essential context for an agent to decide to call it. It is front-loaded with the purpose and ends with usage guidance. While somewhat verbose, the information density justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description fully covers what an agent needs: what it returns, the categories of signals, and the recommended next step (get_signal). Nothing is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, which is fully covered by the schema itself (100% coverage). Per the rubric, the baseline is 4 for no parameters. The description's note that it 'takes no arguments' reinforces but does not add beyond what the schema already makes obvious.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('published signals') and details the exact content (name, one-line description, source URL) across three named applications. It clearly distinguishes itself from the sibling get_signal by stating it returns summaries, not full readings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Call this first to discover signal names, then get_signal for one full reading,' providing both when-to-use and the preferred follow-up tool. This is unambiguous guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_economic_observationsQuery China economic observationsAInspect the native publication-rights status for the China-economic observation surface. The reviewed default-deny policy does not authorize redistribution of current CFETS/ChinaMoney values, so this tool returns policy digest, UTC clocks, per-source decisions and zero published-record status only. It never reads or returns observation rows, empty row arrays, derived signals, or neutral replacements. Filters are validated for contract compatibility but cannot override source rights.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of | No | point-in-time cutoff applied to BOTH released_at and collected_at; omitted means the full published ledger | |
| limit | No | ||
| cursor | No | opaque next_cursor from the preceding page | |
| sector | No | exact sector filter | |
| firm_size | No | exact firm_size filter | |
| geography | No | exact geography filter | |
| ownership | No | exact ownership filter | |
| series_id | No | exact series_id filter | |
| source_id | No | exact source_id filter | |
| period_end | No | inclusive upper bound on observation period_end | |
| released_to | No | inclusive upper bound on released_at | |
| period_start | No | inclusive lower bound on observation period_start | |
| released_from | No | inclusive lower bound on released_at | |
| revision_view | No | all visible vintages, or the newest knowable revision per source/series/slice/period | latest-as-of |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses the critical behavioral restriction: default-deny policy prevents redistribution of current CFETS/ChinaMoney values, so the tool returns only policy digest, UTC clocks, per-source decisions, and zero published-record status. It also states that filters cannot override source rights and that observation rows are never read or returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense, front-loaded sentences with no filler. It leads with purpose, immediately states the most important restriction, and every sentence adds necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 14 optional parameters and no output schema, the description explains the non-obvious return behavior and rights context well. It could be slightly more specific about the shape of 'policy digest' and 'per-source decisions,' but the essential expectations are clearly set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 93%, so most parameters are already documented. The description adds valuable cross-cutting semantics by explaining that filters are validated for contract compatibility but cannot override source rights, which applies to all filter parameters and is not inferable from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action ('Inspect') and resource ('native publication-rights status for the China-economic observation surface'). It also explicitly states what the tool returns and does not return, distinguishing it from an ordinary observation-query tool despite the misleading name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this tool to check publication rights and policy status, not to retrieve observation rows. It explicitly excludes observation data retrieval, though it does not name alternative tools or provide an explicit when-not-to-use comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
whats_happeningCross-signal board verdictAJudge whether anything is happening in Chinese censorship right now, across every signal at once: the board's own cross-signal verdict with the multiplicity paid for (false-discovery control) and coverage confounds flagged as measurement artifacts, never findings. Takes no arguments. Use this instead of fetching signals individually and reconciling them yourself; then use get_signal to drill into whichever signal moved. Scope note: this is the censorship board. For the AI-model-evaluation side use get_signal with 'eval-registry', 'eval-assurance' or 'refusal-drift'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds meaningful context by disclosing false-discovery control and that coverage confounds are flagged as measurement artifacts, never findings. This goes beyond simple read-only behavior and clarifies interpretive nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose. Each sentence earns its place: purpose, usage alternative, and scope caveat. No fluff, and the technical terms (e.g., false-discovery control) are dense but precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a parameterless, read-only board verdict tool. It explains what the tool does, when to use it, how to follow up (get_signal), and explicitly separates censorship board from AI-model-evaluation scope. No output schema is present, but no return details are necessary for this conceptual tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema fully covers that with an empty object. The description redundantly states 'Takes no arguments,' which adds no new meaning but is harmless. Baseline 4 is appropriate for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool judges whether anything is happening in Chinese censorship across all signals, with a specific verb ('Judge') and resource ('cross-signal verdict'). It explicitly distinguishes from siblings by advising to use this instead of fetching individual signals and then using get_signal to drill down.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this instead of fetching signals individually and reconciling them yourself; then use get_signal to drill into whichever signal moved.' Also includes a scope note excluding the AI-model-evaluation side and directing to get_signal with specific parameters, giving clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, bound to the signed-in Glama account, and expire after seven days. They contain no email address or other personal information. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!