MCP server that exposes all installed connectors as tools. Each connector resource becomes an MCP tool with tool calls running through a shared pipeline (execute → compile → memory).
Harbor exposes 16 tools across multiple domains (crypto, stocks, GitHub, PostgreSQL, internal memory). While all have names and descriptions, critical gaps exist: (1) Most tools lack explicit input schemas in the source code or schemas are inferred rather than directly visible; (2) Parameter descriptions are minimal or missing type constraints; (3) Output schemas are not documented; (4) Three internal tools (harbor_recall, harbor_remember, harbor_http) have empty input objects with no parameters defined, making their behavior opaque; (5) No error handling guidance or recovery patterns visible; (6) No security annotations despite exposing database queries and HTTP tools. The server demonstrates a connector-based architecture (coingecko, yahoo, github, postgresql via TypeScript SDKs), but lacks the rigor expected for production agent tooling. Most external connectors reference source files like 'connectors/coingecko/src/index.ts' without showing the actual schema definitions, making schema assessment impossible beyond the high-level parameter names provided. Conservative scoring reflects inability to verify schemas in source and minimal parameter documentation.
Get detailed information about a specific cryptocurrency
Get current prices for one or more cryptocurrencies in a target currency
Get trending cryptocurrencies on CoinGecko
List issues for a repository
List pull requests for a repository
List repositories for a GitHub user/org or search repositories
Authenticated HTTP fetching with auth-proxy support
Three internal tools (harbor_recall, harbor_remember, harbor_http) have empty input schemas with no parameter definitions. LLMs cannot determine what data to pass or how to use these tools.
External tool schemas not directly visible in source, referenced via file paths (connectors/coingecko/src/index.ts, etc.) but actual TypeScript schema definitions not provided. Cannot verify if input schemas use proper JSON Schema types, whether all parameters have descriptions, or if output schemas are documented.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Access cross-session memory for contextual information retrieval
Persist analysis notes and contextual information for future sessions
Run a read-only SQL query against PostgreSQL and return rows as JSON
List available schemas in the database
List tables from information_schema.tables
Get current stock quote for one or more symbols (price, change, volume, market cap)
Search for stocks, ETFs, and other securities by name or keyword
Get detailed summary for a stock including profile, financials, and key statistics
Get trending stock symbols in a specific region
Parameter descriptions are minimal. E.g., coingecko.prices has 'Comma-separated CoinGecko coin IDs (e.g. bitcoin,ethereum)' but lacks constraints like max length, required format validation, or dependency notes. PostgreSQL tools mention 'Optional' but do not explain fallback behavior when connection_url is omitted.
No output schemas documented for any tool. LLMs cannot predict response structure, plan downstream tool calls, or extract relevant fields. E.g., what fields does coingecko.prices return? What about pagination in github.repos?
postgresql.query exposes raw SQL execution without visible input validation, injection guards, or error recovery guidance. If a malicious agent or prompt-injected query is passed, no error message guides the LLM to self-correct. 'Invalid SQL' tells it nothing; 'Invalid SQL: syntax error at line 2, SELECT FROM is missing table name' is actionable.
No error categorization or recovery patterns visible. Tools return errors but do not indicate whether they are retryable, user-fixable, or fatal. An LLM cannot determine: 'Should I retry? Ask the user? Or give up?'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible. While most tools are READ_ONLY, harbor_remember is WRITE and could have side effects. Agents need explicit annotations to understand which tools are safe to retry and which are not.
No pagination parameters visible in github.repos, github.issues, github.pull_requests. If these tools return large result sets, responses could exhaust the context window. Baseline: list_* tools should accept limit and offset/cursor parameters and return a total count.
harbor_http tool description is vague: 'Authenticated HTTP fetching with auth-proxy support.' What URLs does it accept? What authentication methods? What response encoding? LLM cannot determine when to use this vs external tools.