SIP News MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: browsing chronological feed, keyword search, semantic search, fetching articles, listing categories, and index management are all well-separated. Descriptions explicitly clarify differences (e.g., search vs. semantic_search).
Naming Consistency3/5
Most tool names follow a verb_noun snake_case pattern (browse_latest_news, get_article, list_categories, search_news, build_semantic_index). However, 'semantic_index_status' and 'semantic_search' are noun phrases without a verb, breaking the pattern and introducing inconsistency.
Tool Count5/5
With 7 tools, the server is well-scoped. It covers all core functionalities for a news archive (browsing, searching, retrieving, and managing the semantic index) without unnecessary bloat.
Completeness4/5
The tool surface is nearly complete for a read-only news server: both chronological and full-text search, plus semantic search, article retrieval, and index management. A minor gap is the lack of a dedicated 'get_article_by_id' tool, but URLs serve as identifiers.
Average 4.3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It states what the tool returns but does not mention that it is read-only, has no side effects, or any rate limits/permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first establishes the core action, second lists details. No fluff, front-loaded, easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description does not need to detail return structure. Already lists key outputs comprehensively. Tool is simple (no params), so description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100%. Description adds no parameter info because none needed, but it is not a deficiency. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it reports the size/coverage of the semantic index. Lists specific outputs (items indexed, date range, languages, model, location, API key status). Differentiates from sibling 'build_semantic_index' which is about building, not status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies checking status, and the sibling 'build_semantic_index' suggests the alternative. However, there is no explicit guidance on when to use this vs other tools (e.g., checking before building).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 transparently describes the returned fields (title, summary, body, word count, category, language) and processing details (whitespace cleaned, markup removed). It also mentions truncation behavior via max_chars. No destructive actions are implied, so this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. Two sentences: one states the purpose, the other lists returned fields. No wasted words, no redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown but indicated), the description need not detail return types. It covers the main return fields and the max_chars parameter behavior. It could mention error handling (e.g., invalid URL) but overall it's fairly complete for a straightforward fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds minimal context: 'url' should come from search_news/browse_latest_news, and 'max_chars' has default 8000, max 40000, min 200, and truncates cleanly. This adds some value but is not essential beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetch and return the full, cleaned text of a single SIP article.' It uses specific verbs (fetch, return) and resource (single SIP article), and distinguishes it from sibling tools like search_news and browse_latest_news which are for finding articles, not retrieving full content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after finding an article via search_news or browse_latest_news, but it does not explicitly state when to use it vs. alternatives, nor does it provide when-not-to-use guidance or mention prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: results are newest-first, automatic pagination until limit or archive exhausted, and each result includes title, summary, date, language, category, and URL. No destructive or rate-limiting details are needed, as it's a read-only search tool. The description is transparent and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs, no fluff. First paragraph explains purpose and result fields, second explains pagination. Every sentence adds value, and the structure is logical and front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema and full schema documentation, the description is nearly complete. It covers search scope, ordering, result fields, pagination, and cross-reference to get_article. One minor gap: it doesn't specify whether the search includes article bodies or just titles, but 'full-text search' implies body content. Otherwise, comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds some extra context: for 'query' it provides examples, for 'limit' it explains that larger values dig deeper into history. However, most parameter descriptions in the schema are already clear, and the description does not significantly enhance understanding beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search across the SIP news archive, with a specific verb ('search'), resource ('news archive'), and scope ('back to ~2012'). It distinguishes itself from siblings like browse_latest_news (browsing without search) and get_article (retrieving full text).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides general guidance (results newest-first, pagination behavior) and cross-references get_article for full text, but it does not explicitly state when to use this tool versus alternatives like browse_latest_news or semantic_search. No 'when not to use' or direct comparison with siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool pages through SIP news, embeds via OpenRouter, stores vectors in ChromaDB, is safe to run repeatedly (only indexes new items by default), and that it can take time for large max_items. This covers key 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences) and front-loaded with the primary purpose. Every sentence adds value: purpose, process, safety/repeatability, and performance characteristic. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (external API calls, indexing process), the description explains the essential steps and context. The existence of an output schema (not shown but indicated) means return values are documented elsewhere. The description is sufficiently complete for an agent to understand when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for parameters: language, max_items, refresh. The schema itself already describes them clearly. The description provides context about how they are used in the process, but no new semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Build or update the local vector index that powers semantic_search.' It uses specific verbs (build/update) and identifies the resource (local vector index). This distinctly differentiates it from sibling tools like browse_latest_news, get_article, or semantic_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Run it once before using semantic_search, and again periodically to pick up new news.' It also notes the tool is safe to run repeatedly and describes default behavior. While it does not mention alternatives or when not to use it, the guidance is clear and context-specific.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behavioral traits: the feed is chronological and newest first, and it is a contextual browse (no search required). It does not mention pagination or authentication, but these are standard for a read-only list tool and output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose, followed by usage details. Every sentence adds value without redundancy or wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, full parameter coverage, and presence of an output schema, the description is complete. It covers the main use case, suggests parameter combinations, and references a sibling tool (list_categories) for further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with clear descriptions (e.g., language de/fr/en, limit 1-200, since/until format, category referencing list_categories). The description adds value by emphasizing the chronological nature and the 'no search query' point, and by recommending combination with other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Browse the latest SIP news, newest first (no search query needed).' It specifies the verb (browse), resource (SIP news), and ordering, distinguishing it from sibling tool 'search_news' which requires a query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to combine with 'since'/'until' for date ranges and 'category' for filtering, providing clear usage patterns. It also states no search query is needed, but does not explicitly exclude cases where search_news would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It transparently describes the tool as a listing operation with no side effects. While it omits details like data freshness or authorization, for a simple read-only tool with no parameters the description is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the purpose and immediately providing usage guidance. Every sentence adds value without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters) and the presence of an output schema, the description completely covers what the tool does and how the output should be used with sibling tools, making it fully actionable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description does not need to add parameter semantics, but it does provide context on the output's usage, which adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists content categories and interface languages, using specific verb ('List') and resource ('content categories and interface languages'). It further distinguishes itself by explaining how the output is used with sibling tools search_news and browse_latest_news.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the agent to use the returned category keys with the `category` parameter of search_news / browse_latest_news, providing clear context on when to use this tool—essentially a prerequisite step for those tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description fully discloses behavior: vector similarity, similarity score range, top_k control, prerequisites, and error messaging for missing index or key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise; two short paragraphs front-loading purpose, then key details. Every sentence is necessary and well-ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (so return format not needed), description covers prerequisites, error handling, parameter usage, and distinguishes from sibling tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3, but description adds value by contextualizing 'query' as natural-language questions and clarifying 'top_k' defaults and purpose beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'meaning-based search over the SIP news index' with vector similarity, and explicitly distinguishes it from the keyword-based sibling 'search_news'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance by contrasting with search_news, explains prerequisites (build_semantic_index and OPENROUTER_API_KEY), and describes error behavior when conditions not met.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![SIP-MCP-Connector MCP server](https://glama.ai/mcp/servers/masterries/SIP-MCP-Connector/badges/card.svg)](https://glama.ai/mcp/servers/masterries/SIP-MCP-Connector)

Score Badge

Copy to your README.md:

[![SIP-MCP-Connector MCP server](https://glama.ai/mcp/servers/masterries/SIP-MCP-Connector/badges/score.svg)](https://glama.ai/mcp/servers/masterries/SIP-MCP-Connector)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/masterries/SIP-MCP-Connector'

If you have feedback or need assistance with the MCP directory API, please join our Discord server