terminal
Server Details
Live geopolitical and markets intelligence wire: 35k+ wire items, event threads, 55k+ articles.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 3.4/5 across 7 of 7 tools scored.
Each tool targets a distinct resource and action: articles, threads, context, wire items, and categories. No two tools have overlapping purposes, making selection unambiguous.
All tools follow a consistent verb_noun pattern with lowercase underscores (e.g., list_articles, get_thread, search_wire), ensuring predictability.
Seven tools is well-scoped for a news terminal server, covering browsing, searching, and retrieval without unnecessary bloat.
The set covers listing, searching, and getting individual items, but lacks a dedicated tool to fetch a single wire item by ID (only search returns lists). This is a minor gap for a read-only service.
Available Tools
7 toolsget_articleAInspect
One full licensed Monexus article as markdown plus metadata (paid, $0.01/req or pass).
Args:
slug: the article slug from list_articles.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It reveals that the tool is paid ($0.01/req) and returns markdown with metadata, but it fails to mention error handling, authentication requirements, or what happens on invalid slugs. The cost disclosure is a positive, but important behavioral aspects are missing.
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 extremely concise, with two short statements and a parameter explanation. It front-loads the core purpose and cost, and every sentence serves a clear function without repetition or filler.
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 simplicity (one parameter, no output schema, no annotations), the description covers the basic purpose and cost but lacks details on return structure, error conditions, and how it compares to siblings like get_context. It is adequate but not thorough.
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 0%, so the description must compensate. It explains the 'slug' parameter as coming from list_articles, adding context beyond the schema's type definition. However, it does not provide format constraints, examples, or edge cases, making the added value minimal for a single parameter.
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 returns a full licensed Monexus article as markdown plus metadata, with an explicit cost. It specifies the required input (slug from list_articles), effectively distinguishing it from sibling tools like get_context or get_thread that serve different purposes.
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 by stating the slug should come from list_articles, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. It lacks exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_contextAInspect
Full context brief for a thread: background, timeline and significance (paid, $0.005/req or pass).
Args:
item_id: the thread/item id to build the context brief for.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses pricing ($0.005/req or pass), which is a behavioral trait. However, with no annotations, it omits other behaviors like read-only nature or response format.
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 extremely concise with one sentence and a parameter definition. Front-loaded with purpose, no wasted words.
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 tool with one parameter and no output schema, the description covers the input and purpose but lacks details about the output format or additional constraints. Adequate but not fully 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 description explains 'item_id' as 'the thread/item id to build the context brief for', adding meaning beyond the schema's type and title. Schema coverage is 0%, so this is valuable.
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 provides a 'full context brief for a thread' including background, timeline, and significance. It distinguishes from sibling tools like get_thread (raw thread) and get_article.
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 use when a context brief is needed but does not explicitly state when not to use or mention alternatives. No guidance on choosing between get_context and get_thread.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_threadBInspect
One event thread with all of its wire items (paid, $0.002/req or pass).
Args:
thread_id: the thread id, as returned by list_threads or search_wire.
| Name | Required | Description | Default |
|---|---|---|---|
| thread_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It mentions that the tool returns an event thread with wire items and includes pricing, but does not disclose whether the operation is read-only, idempotent, or has side effects. Critical information about authentication or rate limits is missing.
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 very concise, consisting of two short sentences. However, the first sentence includes pricing information that could be considered secondary to the core purpose, slightly reducing effectiveness. Overall, it is well-structured for brevity.
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 simplicity (one parameter, no output schema), the description provides the basic information needed: what the tool returns and where the input comes from. However, it lacks details on error handling, output format, or any caveats, which would be helpful for full completeness.
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 description provides essential context for the single parameter 'thread_id' by specifying its source ('as returned by list_threads or search_wire'). This adds meaning beyond the input schema, which only declares the parameter as a required string without additional explanation.
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 that the tool returns 'One event thread with all of its wire items', which clearly indicates the purpose of retrieving a specific thread. However, the inclusion of pricing information and jargon ('wire items') slightly obscures clarity, and the lack of a title reduces immediate understanding.
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 usage guidance is provided. The description does not explain when to use get_thread versus siblings like list_threads or search_wire, leaving the agent to infer the appropriate context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_articlesBInspect
Index of 55,000+ licensed Monexus articles (paid, $0.002/req or pass).
Args:
category: optional category filter.
limit: max articles to return.
before: pagination cursor, return articles published before this timestamp/id.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| before | No | ||
| category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions pricing ($0.002/req) and pagination cursor but does not disclose side effects, authentication needs, or read-only nature. With no annotations, the description should provide more behavioral context.
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?
Short description with clear bullet-point Args section. Front-loaded with purpose and pricing. No extraneous text, though structure could be improved by placing action first.
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?
Covers purpose and parameters adequately for a simple list tool, but lacks output format details and limit constraints. With no output schema, more return structure information would enhance completeness.
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 description coverage is 0%, but the description adds meaning to all three parameters: category filter, limit on articles, and pagination cursor explanation. Improves understanding beyond the schema, though 'before' format is ambiguous.
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?
Description specifies 'Index of 55,000+ licensed Monexus articles', indicating a listing function with a specific resource and scope. Clear verb 'list' and resource 'articles' but could more distinctly separate from sibling tools like 'search_wire'.
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 alternatives (e.g., search_wire, get_article). Parameter descriptions are provided but no context on typical use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAInspect
Beat/category scoreboard with item counts and latest timestamps (free, no key needed).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the tool requires no key and returns counts and timestamps, indicating a read-only operation. However, it does not mention side effects, rate limits, or confirm idempotency, leaving some behavioral aspects unspecified.
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 a single concise sentence that clearly conveys the tool's output and access requirement. No unnecessary words, and it is front-loaded with core purpose.
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 no output schema and zero parameters, the description adequately states what the tool returns (counts and timestamps). It could mention if the list is exhaustive or paginated, but for a simple tool it is sufficiently 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 is empty, so schema description coverage is 100%. The description adds no parameter-specific meaning, but with zero parameters this is acceptable. Baseline 4 applies due to no parameters needing documentation.
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 lists categories/beats as a scoreboard with item counts and latest timestamps. It uses a specific verb and resource, and distinguishes itself from sibling tools like list_articles and list_threads by emphasizing the scoreboard nature and public accessibility.
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 mentions 'free, no key needed' implying public access, but it does not explicitly state when to use this tool versus alternatives like list_articles or search_wire. No guidance on preferred use cases or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_threadsBInspect
Live event threads: wire items clustered into developing stories (paid, $0.002/req or pass).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses cost but says nothing about rate limits, response structure, or side effects. For a read-only list tool, safety is implied but not explicit.
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 very short and front-loaded with key information: what it does and cost. 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?
For a zero-parameter tool with no output schema, the description is adequate but minimal. It lacks context on when to use it and what the output format resembles, but the core purpose is clear.
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 covers 100%. The description adds no parameter info, which is acceptable. Baseline for zero parameters 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 clearly states the tool lists 'live event threads' and explains they are 'wire items clustered into developing stories.' It also mentions cost. However, it does not explicitly distinguish from siblings like list_articles or get_thread.
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 alternatives such as search_wire or get_thread. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_wireBInspect
Latest Monexus Terminal wire items (paid, $0.001/req or pass).
Args:
category: optional beat filter, e.g. geopolitics, business, tech, crypto, sports, science.
query: optional full-text search string.
limit: max items to return (1-100).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| category | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It reveals a cost per request but omits other behaviors such as read-only nature, sorting (implied by 'Latest'), rate limits, or authentication requirements. The cost is useful but insufficient.
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 very concise: a single line for purpose/cost and three lines for parameters. Every sentence adds value, with no redundancy. The structure is front-loaded and easy to scan.
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 no output schema and no annotations, the description covers the core functionality: what is returned, cost, and parameter meanings. However, it lacks details on response format, pagination behavior, and how this tool fits with siblings, leaving some gaps for an AI agent.
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 0% description coverage, so the description must compensate. It provides clear details for all three parameters: category with examples, query as full-text search, and limit with a valid range. This adds significant meaning beyond the bare 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 it retrieves 'Latest Monexus Terminal wire items' with filtering options, which clarifies the verb and resource. However, it does not explicitly distinguish this from sibling tools like list_articles or get_article, leaving ambiguity about when to use each.
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 is provided on when to use this tool versus alternatives. The description mentions pricing ('paid, $0.001/req or pass') but does not explain when this paid tool is appropriate or any preconditions for use.
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.
Discussions
No comments yet. Be the first to start the discussion!