공개 Tempo.co 보도를 위한 의존성 없는 Model Context Protocol (MCP) 서버입니다. 기사 가져오기, Tempo 검색, 기사 수준 리서치 브리프, 그리고 진행 중인 스토리에 대한 비교를 지원합니다.
tempo_search — 쿼리에 대한 공개 Tempo 링크를 찾습니다.
tempo_article — 정규화된 기사 메타데이터, 정리된 텍스트, 그리고 관련 동영상/임베드 메타데이터(있는 경우)를 반환합니다.
tempo_insights — 주장, 엔티티, 날짜, 정량적 신호, 불확실성, 관련 동영상 컨텍스트를 포함한 추출형 브리프를 생성합니다.
tempo_compare — 2~5개 기사를 비교하여 반복되는 엔티티, 주장, 타임라인 신호를 대조합니다.
tempo_auth_status — 비밀을 노출하지 않고 선택적 구독자 인증이 구성되었는지 보고합니다.
분석 도구는 보도를 독립적으로 검증하지 않습니다. 출력물을 가져온 소스에서 추출한 신호로 명확히 표시합니다.
Related MCP server: Real Time News Data MCP Server
Tempo 기사에 관련 동영상이 포함된 경우, 서버는 공개 기사 HTML에서 사용 가능한 정보로부터 유용한 컨텍스트를 추출하려고 시도합니다:
JSON-LD VideoObject, Clip 또는 MediaObject 메타데이터.
OpenGraph 동영상 URL.
YouTube, Vimeo 또는 기타 플레이어 임베드와 같은 임베드된 동영상 iframe.
네이티브 HTML 동영상 소스 및 캡션 트랙 링크.
페이지가 구조화된 메타데이터로 노출하는 경우의 대본 텍스트.
tempo_insights는 해당 동영상 메타데이터 또는 대본 텍스트를 related_video_context 아래의 브리프에 통합합니다. 동영상을 다운로드하거나, 플레이어를 우회하거나, 오디오를 직접 전사하지 않습니다. Tempo가 캡션, 대본, 제목 또는 설명 없이 동영상만 임베드하는 경우, 인사이트는 임베드 메타데이터로 제한됩니다.
다음 서버 정의를 추가하되, 체크아웃 위치가 다른 경우 절대 경로로 대체하세요:
{
"mcpServers": {
"tempo-insights": {
"command": "node",
"args": ["/Users/yudistryanizharkamil/Documents/ChatGPT/Personal/src/index.js"]
}
}
}npm install 단계는 필요하지 않습니다. npm start로 수동 실행하세요.
Tempo.co는 제3자 기사 액세스를 위한 공개 OAuth 흐름을 노출하지 않는 것으로 보입니다. Tempo는 REMP를 사용합니다: 로그인 사용자 토큰은 n_token 쿠키에 있으며 Authorization: Bearer <n_token>으로도 전송됩니다. Hotjar _hjSession_* 또는 _ga와 같은 분석 쿠키는 로그인 자격 증명이 아닙니다.
구독 계정의 경우, MCP는 환경 변수를 통한 인증된 가져오기를 지원합니다:
TEMPO_COOKIE — Cookie 헤더 또는 순수 n_token 값. 추적 쿠키는 제거되며, 순수 토큰은 n_token=...으로 정규화됩니다.
TEMPO_COOKIE_FILE — 해당 쿠키가 포함된 텍스트 파일의 경로. 파일은 모든 요청에서 다시 읽힙니다.
TEMPO_AUTHORIZATION — 선택적 재정의. 생략하면 MCP는 쿠키에서 Bearer <n_token>을 파생합니다.
이것은 Tempo Plus를 우회하지 않습니다. MCP가 계정에서 이미 액세스가 허용된 콘텐츠만 가져올 수 있게 합니다. MCP는 쿠키 값을 출력하지 않습니다.
Chrome에서 Tempo에 로그인한 후 다음을 실행하세요:
npm run cookie:export헬퍼는 로컬 프로필에서 Chrome의 Tempo 쿠키를 읽어 n_token, we_userid, status_user, remp_session_id, remp_session_referer, browser_id만 유지하고 ~/.cursor/tempo.cookie에 기록합니다. 실행하지 않는 한 쿠키를 스크랩하지 않습니다.
그런 다음 Cursor에서 해당 파일을 가리키고 MCP를 다시 로드하세요:
{
"mcpServers": {
"tempo-insights": {
"command": "node",
"args": ["/Users/yudistryanizharkamil/Documents/ChatGPT/Personal/src/index.js"],
"env": {
"TEMPO_COOKIE_FILE": "/Users/yudistryanizharkamil/.cursor/tempo.cookie"
}
}
}
}tempo_auth_status를 사용하여 n_token_present 및 subscribed_cookie_present를 확인하세요. Chrome이 v20 앱 바인딩 암호화를 사용하는 경우, 이미 읽을 수 있는 Tempo Plus 기사의 DevTools에서 Cookie 헤더를 복사하여 같은 파일에 저장하고 다시 실행하세요.
호스트 이름이 tempo.co 또는 Tempo 하위 도메인인 HTTPS 링크만 허용됩니다. 응답은 활성 인증 헤더의 짧은 해시를 키로 5분 동안 메모리에 캐시되어 익명, 정적 쿠키, 쿠키 파일 가져오기가 충돌하지 않습니다. 서버는 브라우저와 유사한 User-Agent를 사용하고, 소스 가져오기는 15초 후 타임아웃되며, 추출된 기사 텍스트는 35,000자로 제한됩니다.
Tempo의 페이지 마크업은 변경될 수 있습니다. 기사 추출기는 메타데이터에 JSON-LD를 먼저 사용하고, 텍스트에는 __NEXT_DATA__ 및 기사 본문 폴백을, 관련 동영상 컨텍스트에는 미디어 폴백을 사용합니다. 페이지가 변경되면 src/index.js에서 extractBody 또는 relatedMedia를 업데이트하세요.
Fetch one public Tempo.co article and return clean text plus normalized metadata. Use this before requesting a deep insight for a particular URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A public www.tempo.co (or Tempo subdomain) article URL. | |
| include_body | No | ||
| include_media | No | Include related video/embed metadata found on the article page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool fetches and returns data, implying a read-only operation, but does not explicitly state whether it is safe, requires authentication (given the presence of tempo_auth_status), or has any side effects or limitations (e.g., only public articles). This lack of behavioral disclosure is a gap.
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?
Two sentences with no filler. The first sentence states the function, and the second gives a clear usage directive. Information is front-loaded and every word is purposeful.
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 tool is relatively simple (one required param) and the description covers the main purpose and a usage hint. However, it lacks an output schema and does not mention behavioral constraints like authentication (despite the existence of tempo_auth_status), error handling, or any caveats about availability of public articles. An agent might not know if it needs to call tempo_auth_status first or what specific metadata fields to expect. So it is adequate but not 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 input schema already describes the url and include_media parameters, providing 67% coverage. The description adds a general sense of the output ('clean text plus normalized metadata') but does not elaborate on the parameters beyond what the schema provides. The include_body parameter lacks a schema description, and the tool description doesn't compensate for that either. Minimal added value over the schema.
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 states a specific verb ('Fetch'), a specific resource ('one public Tempo.co article'), and the output ('clean text plus normalized metadata'). It also hints at a relationship with 'deep insight' (likely tempo_insights), which helps disambiguate from siblings.
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 explicitly says 'Use this before requesting a deep insight for a particular URL', which tells the agent when to use this tool relative to tempo_insights. It does not list other alternatives like tempo_search or tempo_compare, but it provides clear usage context for the primary workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether optional subscriber authentication headers are configured for Tempo fetches. Does not expose secrets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that it does not expose secrets, which is a useful behavioral safety note. However, it does not mention potential side effects (though there likely are none), error behavior, or whether it makes any network calls. The security disclaimer adds value, but for a tool with zero annotations, more explicit behavioral context would be expected.
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?
Two short sentences, front-loaded with the core purpose ('Report whether optional subscriber authentication headers are configured') followed by a valuable safety qualifier ('Does not expose secrets'). Every word earns its place; no fluff.
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 has no parameters and no output schema, the description provides the essential information an agent needs: what the tool reports and a critical security property. It is complete for a status-check tool, with no obvious gaps.
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, so per the rubric the baseline is 4. The description does not need to add parameter meaning since there are none. It correctly focuses on the tool's purpose without unnecessary parameter discussion.
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 'Report' and a precise object 'whether optional subscriber authentication headers are configured for Tempo fetches.' It clearly states what the tool does and distinguishes itself from siblings like tempo_search and tempo_article, which perform different operations. Even without reading the schema, an agent can tell this is a status check.
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 no explicit guidance on when to use this tool versus the sibling tools. It implies it is a read-only status check, but does not state conditions for invocation, such as 'call this before attempting authenticated fetches' or 'use when you need to verify configuration.' Lacks any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 2–5 Tempo.co articles. Highlights shared entities, repeated facts, differing framing, chronology, and reporting gaps. Useful for tracking a developing story.
| Name | Required | Description | Default |
|---|---|---|---|
| urls | Yes | ||
| focus | No | Optional comparison lens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes what the comparison highlights, which is useful, but does not disclose any constraints like authentication requirements, potential latency, or failure modes. The tool appears to be read-only, but this is not explicitly stated. It is not misleading but lacks depth on behavioral traits.
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?
Two concise sentences with no fluff. The core purpose is front-loaded, followed by a use-case example. Every word earns its place.
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 has 2 parameters, no output schema, and no annotations, the description covers purpose, range, and use case, but omits details about the focus parameter and any prerequisites (e.g., whether URLs must be publicly accessible). An agent could likely call the tool correctly but might not understand the full scope of the focus lens or output format.
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 50%; the focus parameter's description ('Optional comparison lens') is vague. The tool description clarifies that the urls parameter should contain article URLs, but it does not elaborate on the focus parameter or its possible values. It adds some meaning to urls but falls short of compensating for the gap on focus.
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 verb ('Compare'), the resource ('Tempo.co articles'), and the scope (2–5 articles). It also lists specific outputs (shared entities, repeated facts, framing, chronology, gaps) and is distinct from sibling tools that search, fetch single articles, or provide insights.
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 with 'Useful for tracking a developing story' but does not explicitly contrast with alternatives like tempo_search or tempo_insights. It implies use when multiple articles exist for comparison, but lacks explicit exclusion criteria or mentions of alternative conditions. Slightly above baseline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a Tempo.co article into a research brief: executive summary, key claims, named entities, timeline signals, numbers, uncertainties, and questions to investigate. It is extractive and explicitly separates reported facts from inferred themes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| focus | No | Optional lens, e.g. 'policy implications', 'company risk', or 'election timeline'. | |
| include_source_text | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose the extractive nature and that it separates facts from inferred themes, which is genuinely useful. However, it fails to mention anything about authentication requirements (the sibling tempo_auth_status hints auth is a real concern), output format, failure modes for non-Tempo URLs, or whether it caches results. For a tool that processes external URLs, these are material gaps.
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?
A single, information-dense sentence that front-loads the primary action and then enumerates the output artifacts. No wasted words, and the extractive/facts-vs-inference clause earns its place by adding behavioral nuance. It is concise without being terse.
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 covers the tool's purpose and output structure well, but with no annotations and no output schema, an agent has to infer the return shape, error behavior (e.g., what happens for non-Tempo URLs or paywalled content), and whether auth is required. For a tool that ingests an external URL and produces a multi-part brief, these operational details matter. The facts-vs-inference separation is a nice touch but doesn't compensate for missing auth and error semantics.
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 only 33%. The description names the focus parameter's purpose indirectly through the research-brief concept, but it doesn't explain what 'focus' does mechanically (narrow the extraction? bias the output structure?) beyond the example lens. The url parameter is obvious from the description ('Tempo.co article'), and include_source_text is self-explanatory from its boolean type. The description adds marginal context but doesn't fully compensate for the coverage gap on 'focus'.
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?
States a specific verb ('Turn into a research brief'), a clear resource (Tempo.co article), and enumerates the output structure (executive summary, key claims, named entities, timeline signals, etc.). It also distinguishes itself by characterizing its approach as 'extractive' with an explicit facts-vs-inference separation, which is unique among the listed siblings.
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?
No guidance on when to use this tool versus tempo_article, tempo_compare, or tempo_search. An agent cannot tell from the description whether it should run tempo_insights or tempo_article for a single article, or whether tempo_compare handles multi-article comparison. Sibling names suggest the comparison tool exists, but the description never mentions alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Tempo.co reporting by a query. Returns article candidates with title, URL, date, description, and section when available.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Indonesian or English search phrase. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that results are 'candidates' with specific fields, but it does not mention potential side effects (e.g., read-only nature), authentication requirements (given sibling tempo_auth_status exists), or pagination/result limits beyond the schema. It provides some behavioral context but leaves gaps.
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, clear, and front-loaded with the main purpose. It avoids redundancy and includes only relevant information about what is returned. No filler or excessive detail.
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 simple search tool, the description covers the query and return fields, but it lacks critical context such as authentication prerequisites (sibling tempo_auth_status implies auth may be needed) and any pagination or limit behavior. It does not mention sorting or how results are ordered, which an agent might need to know. Essential enough to score a 3, but not 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 schema covers 'query' with a description, but 'limit' has no description and the tool description does not mention either parameter. The description adds no value beyond the schema for the query parameter and fails to compensate for the undocumented limit parameter. Since schema coverage is 50% (not low, but not high), the description should at least reference the limit behavior; it does not.
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 states a specific verb ('Search'), resource ('Tempo.co reporting'), and what it returns (article candidates with fields). It clearly distinguishes from siblings like tempo_article (likely retrieval of a specific article) and tempo_insights (likely analysis), so an agent can tell it apart without inspecting other tools.
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 implies usage when you have a query, but it does not explicitly mention when to use this tool versus alternatives. Sibling names suggest tempo_article is for specific article retrieval, but the description does not state 'use tempo_article when you have a direct URL' or similar exclusions. Guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: search, fetch, generate insights, compare, and check auth status. No overlap or ambiguity exists between them, making tool selection straightforward for an agent.
All tools share the 'tempo_' prefix and use snake_case, but there's a mix of verb-led names (tempo_search, tempo_compare) and noun-led names (tempo_article, tempo_insights, tempo_auth_status). Minor inconsistency, but the pattern is still predictable and readable.
With exactly 5 tools, the set is well-scoped and each tool earns its place in the news analysis workflow. This falls comfortably within the ideal range for a specialized server.
The core workflow of searching, fetching, analyzing, and comparing articles is covered, plus a useful auth status check. Minor gaps like bulk fetching or topic discovery exist, but they are not critical to the server's purpose and can be worked around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, read, and automate TextMine documents, records, workflows, integrations, and agent tasks.
Search and analyze global news coverage and US TV transcripts via the GDELT Project APIs.
Summarize URLs, repurpose content, daily news digests, find competitors. Cost telemetry built in.
Real-time web search, reasoning, and research through Perplexity's API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yudistryan/tempo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
