Loading ToolBench
MCP server decoy for deception-based threat detection. Provides fake tools that simulate enterprise integrations (Bitbucket, Cassandra, Elasticsearch, PostgreSQL, Confluence, GitHub, GitLab, Jira, Salesforce, Slack, etc.) with deterministic seeded responses for honeypot/SIEM integration.
MCP Decoy is a deception/honeypot server with 13 tools spanning Bitbucket, Cassandra, Elasticsearch, PostgreSQL, and Confluence. All tools are READ_ONLY and generate deterministic fake data via seeded PRNG. Strengths: clear naming (verb_noun pattern), reasonable descriptions (100-200 chars), and proper JSON Schema with types. Critical weaknesses: parameter descriptions are minimal or absent (most params lack explanation of purpose/constraints), no output schemas documented, no error handling guidance, and no pagination support despite tools returning lists. The server is HTTP-based (good), but lacks modern MCP patterns like tool annotations, structured error recovery, and per-request metadata. Tools are well-named but descriptions don't explain WHEN to use each tool or what distinguishes similar ones (e.g., bitbucket_search_repositories vs bitbucket_search_code).
Searches and retrieves build or pipeline artifacts from Bitbucket Pipelines. Returns artifact metadata including content previews, pipeline information, and download links.
Searches code content within Bitbucket repositories across all or specific workspaces. Returns matching snippets with file paths, line numbers, and highlighted matches.
Searches Bitbucket workspaces for repositories by name, description, or metadata. Returns repository information, URLs, owner details, and project associations.
Executes a SELECT query against a Cassandra keyspace. Returns rows as a list of objects mapping column names to values, along with optional metadata.
Retrieves Cassandra keyspace names, including additional driver-specific metadata (e.g., durable_writes, replication).
Parameter descriptions missing or minimal. Most parameters (query, workspace, repository, keyspace, index, database, title, space) lack explanation of purpose, format, constraints, or examples. LLMs cannot infer whether 'query' accepts regex, wildcards, or exact match.
No output schemas documented. Tools return lists (repositories, code snippets, logs, rows) but no schema defines the structure of returned objects, field names, or types. Agents cannot plan downstream operations without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Returns Cassandra cluster or server details such as cluster name, release version, data centers, and node/host information.
Searches a Confluence page by its title or name. Returns the complete page with body content, labels, and metadata.
Returns Elasticsearch cluster details such as cluster name, status/health, number of nodes, version, and node roles.
Returns a list of Elasticsearch indices, such as name, health/status, document count, and store size.
Searches Elasticsearch log indices. Returns log hits (timestamp, message, host, service, level), total hit count, and aggregations.
Executes a SELECT query against PostgreSQL. Returns rows as objects with column-value mappings and optional column metadata.
Retrieves a list of PostgreSQL database names, including owner and size details.
Returns PostgreSQL server and version information, including current database and settings snapshot.
No pagination support. Tools returning lists (search_repositories, search_code, list_keyspaces, list_indices, list_databases) lack limit, offset, or cursor parameters. Large result sets will blow context windows without pagination.
No error handling guidance. Tools lack descriptions of failure modes, recovery steps, or actionable error messages. If a query fails, agents have no guidance on whether to retry, adjust parameters, or ask the user.
Tool descriptions lack WHEN/WHY context. Descriptions state WHAT each tool does but not when to use it instead of similar tools. E.g., bitbucket_search_repositories vs bitbucket_search_code, when should an agent pick one over the other?