Live internet-censorship signals and tamper-evident, pre-registered, hash-chained AI model evals.
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.7/5 across 4 of 4 tools scored.
Each tool has a clearly distinct purpose: list_signals for discovery, get_signal for a single named signal, gfw_reading for a specific combined view, and whats_happening for a cross-signal verdict. Descriptions explicitly clarify boundaries, such as when to use get_signal instead of gfw_reading.
Tool names mix conventions: get_signal and list_signals are verb_noun, gfw_reading is noun_gerund, and whats_happening is a question phrase. While all use underscores and are readable, the pattern is not uniform, making it less predictable.
Four tools is well-scoped for a read-only observatory. Each tool covers a distinct need: discovery, single-signal access, a specialized combined view, and an aggregate verdict. The count feels complete without excess or deficiency.
The tool set covers core observatory functions: listing, reading individual signals, a combined GFW view, and a summary verdict. A minor gap is lack of historical data access, but the current surface supports the intended workflows well.
get_signalOne signal's full readingARead the full latest published reading of one named signal: the raw payload with its generated_at timestamp, method scope and upstream sources, exactly as served on palimpsest.info. 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, and 'refusal-drift' returns the current frontier-model refusal reading on the frozen benign probe set. 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' 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?
Even with annotations indicating read-only and idempotent behavior, the description adds valuable context: it describes the exact response shape, mentions special named signals and their distinct return formats, and discloses that caps on long arrays are reported with the true total rather than silently truncated. This goes well beyond the annotations and gives the agent a clear model of the tool's behavior.
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 efficiently structured: it leads with the core purpose, follows with prerequisites and special cases, and closes with a sibling distinction. Every sentence adds distinct value—no filler, redundancy, or re-stating of the tool name. The format is easy to scan and front-loaded.
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 without an output schema, the description is remarkably complete: it explains what is returned, how to discover valid names, special-cases two named signals with their specific return structures, and notes the difference from a sibling. The max_rows parameter is fully documented in the schema, which the description complements. The agent has all the information needed to invoke 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?
The schema covers 100% of parameters, providing baseline 3. The description adds extra semantics for the 'name' parameter by giving concrete examples ('ooni-gfw', 'eval-registry', 'refusal-drift') and instructing users to call list_signals first. It does not discuss 'max_rows' directly, but the schema description is thorough, so the description's contribution earns a 4 rather than a 5.
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 starts with a specific verb and resource: 'Read the full latest published reading of one named signal', and details the exact contents (raw payload, timestamp, method scope, upstream sources). It explicitly distinguishes the tool from the sibling gfw_reading, stating that gfw_reading merges the Great Firewall layers instead. This leaves no ambiguity about what the tool does.
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 usage guidance: 'Call list_signals first to discover valid names', explains when to use it for AI-model-evaluation signals ('eval-registry', 'refusal-drift'), and explicitly differentiates from gfw_reading. It also advises on parameter sizing with the max_rows default, indicating a practical usage tip for keeping calls responsive.
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 both of its 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. AI model evaluation — the tamper-evident, pre-registered eval registry (hash-chained and Merkle-anchored) and frontier-model refusal drift, alongside the Generative Firewall Index over Chinese LLMs. 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. The description adds context about the two application domains (censorship/information control and AI model evaluation) and the specific signal families included, as well as the return fields. This goes beyond the annotations without contradicting them.
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, followed by concrete examples of signal categories that add context, and ends with actionable usage guidance. Each sentence is informative; the length is justified by the richness of the signal taxonomy.
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?
With no output schema, the description compensates by listing the output fields (name, one-line description, source URL) and describing the tool's role as the discovery entry point before get_signal. Given its simplicity and strong annotations, no critical information is missing.
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 has zero parameters and the schema is empty. The description explicitly states 'Takes no arguments,' which is consistent with the schema and leaves no ambiguity. The baseline for zero parameters is 4, and the description meets it.
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 a specific action: 'List every published signal Palimpsest exposes' and specifies the output fields (name, one-line description, source URL). It differentiates from the sibling get_signal by stating 'Call this first to discover signal names, then get_signal for one full reading.'
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?
Explicit usage guidance is given: 'Takes no arguments. Call this first to discover signal names, then get_signal for one full reading.' This clearly tells the agent when to use this tool and how it relates to the get_signal alternative.
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' 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=true and idempotentHint=true, and the description adds useful context about the statistical control ('multiplicity paid for (false-discovery control)') and how to interpret artifacts ('coverage confounds flagged as measurement artifacts, never findings'). This goes beyond the annotations by setting expectations for the verdict's nature, though it doesn't detail return structure.
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, each earned: first states the core purpose, second gives when-to-use and follow-up action, third provides scope differentiation. No fluff or repetition, and the key action is front-loaded.
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?
Despite no output schema, the description sufficiently orients the agent: it explains what the verdict is, how to use it, and when to use alternatives. A slight gap is that it doesn't describe the shape of the verdict, but for a zero-argument tool with strong usage guidance, this is nearly complete.
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, so the baseline is 4. The description explicitly states 'Takes no arguments', which is consistent with the empty schema and leaves no ambiguity for invocation.
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 'Judge' and clearly identifies the resource: 'whether anything is happening in Chinese censorship right now, across every signal at once'. It distinguishes from siblings by positioning itself as the cross-signal aggregation tool, saying 'Use this instead of fetching signals individually', and the scope note differentiates from get_signal's AI-model-evaluation side.
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?
Explicit guidance is given: 'Use this instead of fetching signals individually and reconciling them yourself; then use get_signal to drill into whichever signal moved.' It also clarifies scope boundaries ('this is the censorship board') and provides an alternative for the other domain ('For the AI-model-evaluation side use get_signal with eval-registry or refusal-drift').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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!