periscope-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AGNES_API_KEY | No | API key for the Agnes provider (default, free tier). | |
| DOUBAO_API_KEY | No | API key for the Doubao (豆包) provider. | |
| GOOGLE_API_KEY | No | API key for the Gemini provider. | |
| OPENAI_API_KEY | No | API key for the OpenAI provider. | |
| MINIMAX_API_KEY | No | API key for the MiniMax provider. | |
| DEEPSEEK_API_KEY | No | API key for the DeepSeek provider. | |
| ANTHROPIC_API_KEY | No | API key for the Anthropic provider. | |
| DASHSCOPE_API_KEY | No | API key for the Ali (Qwen / 通义千问) provider. | |
| AZURE_OPENAI_API_KEY | No | API key for the Azure OpenAI provider (used together with AZURE_OPENAI_ENDPOINT). | |
| AZURE_OPENAI_ENDPOINT | No | Endpoint for the Azure OpenAI provider (used together with AZURE_OPENAI_API_KEY). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ps_validate_configC | Validate Periscope config and required environment variables. |
| ps_fetch_itemsC | Fetch and deduplicate content into the raw stage. |
| ps_score_itemsD | Score a stage into the scored stage. |
| ps_filter_itemsC | Filter scored items into the filtered stage. |
| ps_enrich_itemsC | Enrich filtered items into the enriched stage. |
| ps_generate_summaryC | Generate a markdown summary from a stage. |
| ps_run_pipelineC | Run fetch -> score -> filter -> enrich -> summarize in one call. |
| ps_list_runsC | List recent runs and stage states. |
| ps_get_run_metaC | Read run metadata. |
| ps_get_run_stageC | Read items from a run stage. |
| ps_get_run_summaryC | Read a generated run summary. |
| ps_get_metricsB | Read in-memory server metrics. |
| ps_corpus_statsB | Evidence-corpus overview: stored items by source, clusters, runs, plus claim and research-session counters. The 'what do we already know' probe. |
| ps_corpus_searchC | Full-text search over every item ever collected (BM25, CJK-aware). |
| ps_corpus_recentC | Most recently published items in the corpus, optionally one source. |
| ps_corpus_importA | Import a user export ({"items": [...]}) into the evidence corpus. Each item declares its own authorship tiers through
|
| ps_list_claimsC | Claims by pipeline status (extracted | linked | graded) with verdicts, confidence, trust, ungraded_reason and independent-source counts. |
| ps_get_claimB | One claim in full: verdict, evidence rows, source independence. |
| ps_research_startB | Open a long-session research task: decompose the question, investigate each sub-question against the corpus, return a cited markdown report. State persists — follow up later, even after restarts. |
| ps_research_followupB | Push back on an existing session: the message can narrow, expand or challenge; the sub-question tree is revised and the report re-rendered. |
| ps_research_stepB | Advance a research session by ONE round and get back the delta. The loop chooses a verb each round: deepen a branch, fold the message into
the question tree, finalise — or ask you for something only you can supply
(then |
| ps_research_draftB | Read the research document as a versioned draft: revision, origin
(render | user_edit | merge), and per-section state — locked, stale, and
the evidence item ids behind each section. Omit |
| ps_research_editB | Rewrite one section as the author. Stored as its own revision and locked, so a later recompute marks it stale instead of overwriting your prose. |
| ps_research_answerB | Reply to a question the session asked ( |
| ps_research_statusC | Session state: sub-question tree with statuses/answers/evidence ids, turn history, and the current rendered report. |
| ps_research_listC | Recent research sessions with their questions and statuses. |
| ps_send_webhookB | Send a webhook notification with the given variables. Uses the webhook URL (from environment variable), request_body template, and headers from the Periscope config. Template variables #{date}, #{language}, #{important_items}, #{all_items}, #{result}, #{timestamp}, #{summary} are replaced in the URL and request_body before sending. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| r_server_info | Server metadata resource. |
| r_metrics | In-memory metrics snapshot. |
| r_runs | Recent run list. |
| r_effective_config | Effective default config resolved from local Periscope path. |
TDQS
Scored across 27 tools
Most tools target a clear resource+action: individual pipeline stages (fetch/score/filter/enrich), distinct run reads (meta/stage/summary), and distinct research lifecycle steps. Minor overlaps exist between ps_generate_summary vs ps_get_run_summary, ps_corpus_stats vs ps_get_metrics, and ps_corpus_search vs ps_corpus_recent, but descriptions differentiate them adequately.
All tools share a consistent ps_ snake_case prefix, which makes the set highly scannable. The only deviation is that some names are verb-first (ps_get_claim, ps_list_runs, ps_validate_config) while others are domain-first (ps_corpus_search, ps_research_start), but the pattern remains predictable within each domain.
At 27 tools this is heavier than typical, though the server genuinely spans several domains (corpus, claims, pipeline stages, research sessions, webhook). The eight individual pipeline-stage tools plus ps_run_pipeline create some redundancy, so the surface could be trimmed.
Coverage is broad and lifecycled: corpus ingest/search/stats, claim inspection, full pipeline plus per-stage control, research start/followup/step/draft/edit/answer/status/list, and webhook notify. Only minor gaps exist (e.g., no explicit corpus/claim deletion or run cancellation), which agents can work around.