Infobroker

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct: fetch_page, reload_config, providers, and kb each target unique concerns. The only potential overlap is between web_search and corroborate, but the descriptions clarify that web_search is the unified single-pass search while corroborate is specifically for multi-pass cross-source verification, reducing ambiguity.
Naming Consistency2/5
Tool names do not follow a consistent pattern. Some use verb_noun (web_search, fetch_page, reload_config), while others are single verbs (corroborate), nouns (providers), or abbreviations (kb). Although all share the infobroker_ prefix, the unpredictable suffixes make it hard to infer tool purpose from the name alone.
Tool Count5/5
With 6 tools, the server is well-scoped. Each tool covers a distinct functional area—search, page fetching, configuration reload, provider management, advanced corroboration, and knowledge base operations—without redundancy or unnecessary overhead.
Completeness5/5
The tool set covers the full information-brokering lifecycle: search and fetch for acquisition, corroborate for verification, KB for storage and retrieval (including delete and encryption management), and admin tools for providers and config reload. There are no obvious dead ends or missing critical operations.
Average 2.9/5 across 6 of 6 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 88 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
With no annotations, the description must bear the burden of behavioral disclosure. It hints at 'task-type routing' and 'fallback chain' but does not explain what these entail, what side effects exist, or how failures are handled. No mention of rate limits, auth, or what gets modified (it appears read-only, but not stated). It is not contradictory, but severely under-informs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is dense with jargon ('unified provider search', 'task-type routing', 'fallback chain') without unpacking them. It is not concise in the sense of efficiently conveying information; it is vague and doesn't front-load the most critical info (what the query is for).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, 4 enums, and no output schema or annotations, this description is drastically incomplete. The agent lacks critical information about how to construct a query, what each enum value means, what the response format is, and how routing and fallback affect results. A tool with this complexity requires far more detail to be usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 30%, meaning 7 of 10 parameters lack descriptions. The tool description does not compensate by explaining any parameter meanings, defaults, or relationships. An agent has to infer from names like 'query', 'region', 'priority', etc., which may be ambiguous. The description adds zero value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a general operation: 'Unified provider search' indicates a search over providers, with routing, fallback, and suggestions. It is not a tautology, but it lacks specificity about what is being searched or what 'provider' means. It does not clearly distinguish from sibling tools like infobroker_corroborate or infobroker_kb, which could also involve search-like behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 its siblings. The description does not mention alternatives, prerequisites, or scenarios where this tool is preferred. An agent has no information about when to choose infobroker_web_search over infobroker_fetch_page or infobroker_corroborate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only mentions 'multi-pass' and 'cross-source verification,' but does not describe side effects, return structure, potential rate limits, or what happens with conflicting sources. An agent cannot predict the tool's behavior beyond the vague concept of multi-pass verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, so it is concise and front-loaded with the key concept. However, its extreme brevity borders on under-specification, which is more of a completeness issue. For conciseness alone, it earns a strong score because it avoids waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters (one required), no output schema, and no annotations, the description is notably incomplete. It does not explain what the tool returns, how to interpret results, when to adjust `max_iterations` or `confidence_threshold`, or any caveats. An agent would likely need to experiment or rely on other documentation to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with `query` and `providers` described in the schema, but `max_iterations` and `confidence_threshold` have no schema descriptions. The description adds no parameter meaning at all; it neither explains what these parameters control nor how they relate to the 'multi-pass' behavior. With low coverage, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'multi-pass truth-finding search with cross-source verification,' which indicates a search tool that verifies across sources. However, it is vague about what the tool actually returns or produces, and it does not clearly differentiate it from the sibling `infobroker_web_search`. The verb 'corroborate' implies validation, but the description does not specify the resource or output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the sibling `infobroker_web_search`. The description does not explain the situations that would call for multi-pass truth-finding versus a standard web search, nor does it mention alternative tools or exclusions. Usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal one genuine behavior — the default extraction path (Jina Reader) with a native HTTP fallback. But it silently omits the semantics of the other five renderer modes (wikipedia, internet_archive, arxiv, stack_exchange are opaque), failure/redirect behavior, and truncation behavior tied to max_length. No contradiction exists since there are no annotations, but the disclosure is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words and the core purpose front-loaded in the first sentence — structurally efficient. However, for a tool exposing a 6-option enum with opaque values and a truncation parameter, this is under-sized rather than appropriately concise. Efficient formatting at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters (one an opaque 6-value enum), no annotations, and no output schema — so the description must be rich to compensate, and it is not. Missing: explanation of the six renderer modes, max_length semantics, what the extraction returns, and failure handling. For a fetch tool with this complexity, the description is well short of adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (url only), so the description was required to compensate for renderer and max_length. It barely does: the only nod is 'Jina Reader by default,' which telegraphs the renderer's default. The six enum options are completely unexplained (what does a 'wikipedia' or 'stack_exchange' renderer do?), and max_length's units/semantics never appear. The description adds almost nothing beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Fetch and extract URL content') and adds the dominant mechanism (Jina Reader, HTTP fallback). This is clearly distinct from the siblings (web_search, corroborate, kb, providers, reload_config), though the differentiation is implicit rather than explicit — the description never names an alternative. Clear purpose, but no stated sibling contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance whatsoever. The description says what the tool does but gives no context for choosing it over infobroker_web_search (which could arguably also retrieve content) or infobroker_corroborate. No exclusions, no alternatives, no mention of prerequisites. An agent gets zero decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It labels actions as 'list, health, or spec,' which implies read-only operations, but it does not explicitly state that it does not mutate state, nor does it mention any side effects, permissions, or response behavior. The phrase 'operational state' is vague and does not clarify what an agent should expect regarding preconditions or consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose and action list. There is no repetitive or wasted wording. It loses a point because it is so terse that it omits useful clarifications (e.g., which params apply to which action), but for pure conciseness it is well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should explain what each action returns or what the operational state encompasses. It does not describe the output format, whether 'health' returns status codes, whether 'spec' returns configuration details, or how 'status' filters listing. For a tool with three distinct actions, the missing behavioral and output context makes it incomplete for an agent to correctly invoke and interpret results.
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?
The schema provides full descriptions for all parameters (action enum, status filter, provider slug) with 100% coverage, so the baseline is 3. The description adds minimal extra meaning beyond restating the action names; it does not elaborate on relationships like 'provider is required for health' or how status interacts with list. While it does reinforce the enum values, it does not elevate understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool deals with operational state over configured providers and enumerates the actions (list, health, spec). This clearly identifies the resource (providers) and the operations, differentiating it from sibling tools like web_search or fetch_page. However, phrasing 'operational state over' is slightly indirect – it could be more explicit like 'manage or inspect configured providers' – so it doesn't reach a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Sibling tools operate on different domains (search, page fetch, reload config, corroborate, KB), but the description does not mention them or state conditions for selection. The agent is left to infer that this is for provider-specific operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It does not disclose that 'delete' is destructive, that encryption operations have security implications (e.g., losing a key locks data), or any side effects like overwriting files. It mentions re-keying but not its consequences. This is a significant gap for a tool with 14 parameters and multiple operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no fluff. It front-loads the core purpose and then gives a targeted use case. However, the list of actions is packed into one sentence and the encryption sentence is separate; a slightly more structured layout (e.g., bullet points) could improve scannability, but it's still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 actions, 14 parameters, and sub-operations, the description is incomplete. It does not explain which parameters are required for each action, how search differs from list/get, or what the encryption operations do beyond naming them. No output schema exists, so description should compensate by clarifying expected return types. It only covers the report-archiving workflow well.
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 93%, so the schema already documents most parameters. The description adds one meaningful hint: pairing source_type 'report' with save_to 'kb' for archiving. However, it does not clarify per-action required parameters or the interplay between url/text/query, which the schema leaves ambiguous. Baseline 3 is appropriate given high schema coverage.
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 'Manage the local knowledge base' and enumerates the specific actions: search, ingest, list, get, stats, delete. It also gives a concrete use case (archive generated reports with ingest, revisit with list/get). This distinguishes it from siblings like infobroker_web_search and infobroker_fetch_page, which are about external content.
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?
Provides explicit usage guidance: 'use ingest with source_type 'report' and save_to 'kb' (default) to archive generated reports; use list/get to revisit them.' It also mentions the encryption sub-actions. However, it does not cover when to use other actions or explicit exclusions/alternatives, but the given guidance is actionable and relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose one behavioral trait ('Active connections are preserved') which is valuable, but it does not mention error handling, side effects, or what happens if the reload fails. It's a minimal disclosure.
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 short sentences with zero filler. The core action and key constraint are front-loaded, and every word contributes meaning. Excellent conciseness.
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?
For a zero-parameter, no-output-schema tool, the description adequately explains the action and a key behavior. It does not describe the return value or failure outcomes, but given the simplicity, it covers the essential context needed to invoke it correctly.
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 input schema is trivially complete. The description adds no parameter details because none are needed. Baseline for 0 params is 4, and there is no deficit.
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 states a specific verb ('re-read') and resource ('config') and adds a key modifier ('without restarting'). It is clearly distinct from sibling tools (web_search, fetch_page, etc.) which all involve data access rather than configuration management.
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 phrase 'without restarting' implies a scenario (apply config changes without downtime) but there is no explicit statement of when to use this tool versus alternatives, nor any exclusions or prerequisites. Usage context is only implicit.
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:

[![infobroker MCP server](https://glama.ai/mcp/servers/flukeatzerocool/infobroker/badges/card.svg)](https://glama.ai/mcp/servers/flukeatzerocool/infobroker)

Score Badge

Copy to your README.md:

[![infobroker MCP server](https://glama.ai/mcp/servers/flukeatzerocool/infobroker/badges/score.svg)](https://glama.ai/mcp/servers/flukeatzerocool/infobroker)

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/flukeatzerocool/infobroker'

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