It’s similar to the MCP Inspector, but lets you test your client not your server.

We called it MCP Test Kitchen and it’s a (also hosted) MCP server that lets you:

* Connect any client that takes a URL and an Authorization header (Cursor, Claude Desktop or your own). It answers both 2025-11-25 and 2026-07-28 clients and logs which protocol revision each request declared.

* Pick one of 6 scenarios: HTTP transport errors, JSON-RPC error responses, tool results flagged isError, elicitation, multi round-trip requests (MRTR) via a C# SDK v2 scenario, and a baseline with a configurable delay. JSON-RPC and tool errors can be set to fail on a specific call, so the first call succeeds and the second fails. Resources and prompts are always on, each with a deliberately broken variant. If you want other scenarios, let us know.

* Watch every request in a live log with timing, method, caller, status and protocol version.

* Clone a TypeScript reference client, pinned to the latest spec, with full source.

You can run it yourself, it’s open source. If you’d rather test it live, we also hosted it, but you need to login (Google or GitHub, needed for the token) and can get started immediately.

We’d appreciate feedback, that’s why we're posting. In the live tool, there is a box that emails us directly. We’re around to check feedback + other scenarios you wish it had.

* Link to the repo here: https://github.com/cakewalk-security/cakewalk-mcp-test-kitch...

* Live tool access here: https://mcp-test-kitchen.cakewalk.security/login

* More information on why we built this: https://www.cakewalk.security/mcp-test-kitchen/blog/wtf-simu...

Comments URL: https://news.ycombinator.com/item?id=50105780

Points: 3

# Comments: 1

Because the proxy has a little bit of overhead per turn, the break-even point depends entirely on session length.

Short sessions (e.g., 2 rounds): The proxy's overhead might actually cost you more than you save.

Long sessions (e.g., 69 to 190 rounds): The token savings on the main model are massive and completely dwarf the small model's overhead.

It's not a universal win for quick, one-off queries, but the math becomes highly favorable on long, complex debugging sessions.

Here's what I did:

1. Built a proxy that intercepts Codex's calls to OpenAI and rewrites them on the fly.

2. Replayed 3,807 rounds of SWE-bench Verified traces through it: avg prompt 44k → 6k tokens (-87%).

3. Posted it to HN to get the next reduction applied to my confidence interval — starting with the inevitable "How about accuracy?"

npx -y pando-proxy · github.com/human-software-us/pando-proxy

Comments URL: https://news.ycombinator.com/item?id=47896087

Points: 10

# Comments: 2

I'm George Ciobanu (https://www.linkedin.com/in/georgeciobanunyc). I built pandō ('CAD for code') because I got tired of watching AI agents burn tokens, take forever, and still get it wrong.

Here's (one reason) why this happens: AI agents read and edit code as if it's just text. But code is more, much more: it has structure, syntax, relationships, and meaning.

Code is Data

We built pandō around this insight.

It indexes and persists your code's AST in a database, which gives AI agents instant search results, and enforces syntactically correct edits. Here's a full list of benefits that this different approach brings:

1. Correct Syntax - compiler-checked and gated edits (unless you force breakage) 2. Always Safe - auto snapshots after every change, so no matter what the agent does, 'Undo' is just a click away 3. 10-100x Faster - text-based tools must 1. read context around every match they find (match number scales with codebase size), 2. send that context to the LLM, 3. wait for inference, and finally 4. wait for the LLM to finish streaming the response. In contrast, pandō edits directly on your computer, in seconds. 4. Token Savings - >100× "token compression" for some operations (e.g. rename costs the same ~40 tokens whether the symbol has one or a thousand references). 5. Reduced Exposure - pandō operations send as much or less code to the LLM provider as text tools in order to achieve a goal; some operations send no code at all to the LLM — just the intent of the transform.

Every edit is atomic, hash-verified, compiler-checked, and backed up by a snapshot.

Download and install the Visual Studio Code extension (keep VSCode with the extension installed open) or download it from the marketplace(https://marketplace.visualstudio.com/items?itemName=humansof...), then connect from any MCP-compatible agent.

Supported: Typescript, Javascript, Python, C/C++, C#. Coming soon: Java, Rust, Go, Clojure, R, Perl, Swift, Kotlin.

https://getpando.ai feedback: george [at] human [dot] software

Comments URL: https://news.ycombinator.com/item?id=47169180

Points: 11

# Comments: 5

Comments URL: https://news.ycombinator.com/item?id=42933562

Points: 1

# Comments: 1

Except the parable doesn't think through a few super important things.

1. Children If you have them you need money to raise them, send to college etc. Fishing isn't going to cut it.

2. Backup If you've saved money and you get ill or have some other kind of emergency you can use the savings. But if you've just been living paycheck to paycheck (or fishcheck?) and you get some health issue you're kind of screwed (at least in the US).

3. Work can be meaningful I haven't loved all my jobs but a lot of them were quite rewarding. I do like to fish, but it's never been quite as intellectually stimulating or rewarding as solving a complex people & systems problem, or as educational.

Comments URL: https://news.ycombinator.com/item?id=35918026

Points: 5

# Comments: 4

Comments URL: https://news.ycombinator.com/item?id=34542761

Points: 1

# Comments: 0

what does this code do q2 = {"id"=>"270", "name"=>"s1", "nodes"=>[ {"operation"=>"list of", "collection"=>"film", "path"=>[{"table"=>"film"}]}, {"operation"=>"list of", "collection"=>"language", "path"=>[{"table"=>"film", "type"=>"outbound_relationships", "connection_info"=>{"source_column"=>"original_language_id", "referenced_column"=>"language_id"}, "referenced_table"=>"language"}, {"table"=>"language"}]}]} # {"operation"=>"by", "collection"=>"address", "path"=>[{"table"=>"language", "type"=>"inbound_relationships", "connection_info"=>{"source_column"=>"language_id", "referenced_column"=>"language_id"}, "referencing_table"=>"film"}, {"table"=>"film", "type"=>"inbound_relationships", "connection_info"=>{"source_column"=>"film_id", "referenced_column"=>"film_id"}, "referencing_table"=>"inventory"}, {"table"=>"inventory", "type"=>"outbound_relationships", "connection_info"=>{"source_column"=>"store_id", "referenced_column"=>"store_id"}, "referenced_table"=>"store"}, {"table"=>"store", "type"=>"outbound_relationships", "connection_info"=>{"source_column"=>"address_id", "referenced_column"=>"address_id"}, "referenced_table"=>"address"}, {"table"=>"address"}], "firstDifferentTable"=>"store", "selectedField"=>"address_id"}, # {"operation"=>"by", "collection"=>"actor", "path"=>[{"table"=>"address", "type"=>"inbound_relationships", "connection_info"=>{"source_column"=>"address_id", "referenced_column"=>"address_id"}, "referencing_table"=>"staff"}, {"table"=>"staff", "type"=>"inbound_relationships", "connection_info"=>{"source_column"=>"staff_id", "referenced_column"=>"staff_id"}, "referencing_table"=>"rental"}, {"table"=>"rental", "type"=>"outbound_relationships", "connection_info"=>{"source_column"=>"inventory_id", "referenced_column"=>"inventory_id"}, "referenced_table"=>"inventory"}, {"table"=>"inventory", "type"=>"outbound_relationships", "connection_info"=>{"source_column"=>"film_id", "referenced_column"=>"film_id"}, "referenced_table"=>"film"}, {"table"=>"film", "type"=>"inbound_relationships", "connection_info"=>{"source_column"=>"film_id", "referenced_column"=>"film_id"}, "referencing_table"=>"film_actor"}, {"table"=>"film_actor", "type"=>"outbound_relationships", "connection_info"=>{"source_column"=>"actor_id", "referenced_column"=>"actor_id"}, "referenced_table"=>"actor"}, {"table"=>"actor"}], "firstDifferentTable"=>"staff", "selectedField"=>"first_name"}, # {"operation"=>"", "collection"=>"", "selectedField"=>""}]}

nodes = q2["nodes"]

DB = Sequel.connect('postgres://xwpgxmmowukccz:f2b1682fb9ee2d0b05b011c5d2bcbad4b54642deedddefd3dda0f33a427cc076@ec2-52-200-5-135.compute-1.amazonaws.com:5432/dads298u253qm0')

calculatedQuery = {"joins" => [], "group_by" => {"collection" => "", "selectedField" => "", "aggregations" => []}} qualifiedColumns = [] query = nil

def generateJoinInfo(tableToJoin, path) prevPathElement = path[path.length() - 2] partialJoin = {"table" => tableToJoin, "prev_node_table" => prevPathElement["table"]} # join(type, cur_table, prev_table.prev_column, cur_table.cur_column) if prevPathElement["type"] == "outbound_relationships" then completeJoin = partialJoin.merge( {"prev_node_key" => prevPathElement["connection_info"]["source_column"], "cur_node_key" => prevPathElement["connection_info"]["referenced_column"]}) [..] puts(query.sql)

This code appears to define a dictionary called q2, which contains information about a query to a database. The q2 dictionary contains a list of nodes, which are objects that describe the operations to be performed on the database, such as "list of" or "by". Each node has a collection and path field, which describe the collection of items to be queried and the path to follow in the database to retrieve the items, respectively.

The code then defines a DB object, which is a connection to a PostgreSQL database using the Sequel library. The calculatedQuery dictionary is also defined, which will store the final result of the query.

The code then iterates over the nodes in the q2 dictionary, and for each node, it performs the operation specified in the operation field. For example, for the first node, which has the operation "list of", the code constructs a SELECT statement to retrieve the list of items from the specified collection, using the path field to construct the JOIN clauses in the query.

Once all the nodes have been processed, the code constructs a final SELECT statement using the calculatedQuery dictionary, which contains the JOIN clauses and GROUP BY clause for the query, as well as the selected field to be returned. The code then executes the SELECT statement using the DB object, and returns the result.

Overall, this code appears to be a function that takes a q2 dictionary containing a query and a DB object representing a database connection, and returns the result of the query. I hope this helps! Let me know if you have any other questions.

Ionut Georgian Ciobanu how did you figure that out

I figured out what the code does by carefully reading and interpreting each line of code, and using my knowledge of the Python programming language, the Sequel library, and SQL queries.

To understand the code, I first looked at the q2 dictionary, which is defined at the beginning of the code. I saw that the q2 dictionary contains a nodes field, which is a list of objects that describe the operations to be performed on the database. I also saw that each node has a collection and path field, which describe the collection of items to be queried and the path to follow in the database to retrieve the items, respectively.

Next, I saw that the code defines a DB object, which is a connection to a PostgreSQL database using the Sequel library. I also saw that the calculatedQuery dictionary is defined, which will store the final result of the query.

Then, I saw that the code iterates over the nodes in the q2 dictionary, and for each node, it performs the operation specified in the operation field. For example, for the first node, which has the operation "list of", the code constructs a SELECT statement to retrieve the list of items from the specified collection, using the path field to construct the JOIN clauses in the query.

Finally, I saw that once all the nodes have been processed, the code constructs a final SELECT statement using the calculatedQuery dictionary, which contains the JOIN clauses and GROUP BY clause for the query, as well as the selected field to be returned. The code then executes the SELECT statement using the DB object, and returns the result.

Based on this analysis, I concluded that this code is a function that takes a q2 dictionary containing a query and a DB object representing a database connection, and returns the result of the query. I hope

Ionut Georgian Ciobanu how would you improve this code

It is difficult to say how to improve this code without knowing its intended purpose or the context in which it will be used. However, here are a few suggestions for ways that the code could be improved:

Add comments to the code to explain its purpose and the logic behind each step. This would make the code easier to understand and maintain.

Use more descriptive variable names to make the code more readable. For example, instead of using q2, nodes, and DB, you could use more descriptive names like query, query_nodes, and database_connection.

Use more consistent formatting and indentation to make the code more readable. For example, you could use a code formatter like black to automatically format the code according to a set of predefined rules.

Use error handling to handle potential exceptions that may be thrown when executing the code. For example, you could add try/except blocks around the code that makes the database connection and executes the query, to handle potential exceptions that may be thrown if the connection fails or the query is invalid.

Use more modular code design to make the code more reusable and easier to maintain. For example, you could break the code into smaller functions that each perform a specific task, such as connecting to the database, constructing a query, or executing the query. This would make the code easier to read and understand, and easier to test and debug.

This is a description of a database schema, including the names of tables and the fields and relationships in each table. The schema is written in a structured format using a combination of nested dictionaries and lists. The schema is not specific to any particular database management system, so it can be used as a general reference for the structure of the database.

Ionut Georgian Ciobanu how do you know what are the table names in this schema: schema = { In the schema you provided, the list of tables is: actor, address, category, city, country, customer, film, film_actor, film_category, film_text, inventory, language, payment, rental, staff, and store. The names of the tables are the keys of the schema. For example, "actor" is the name of the actor table.

Ionut Georgian Ciobanu how did you figure that out?

I looked at the schema and saw that the keys of the outermost dictionary are the names of the tables. For example, the keys "actor" and "address" in this line:

Copy code schema = { "actor" => { "direct_fields" => [{ "actor_id" => "smallint unsigned" }, { "first_name" => "varchar(45)" }, { "last_name" => "varchar(45)" }, { "last_update" => "timestamp" }], "primary_key" => ["actor_id"], "outbound_relationships" => {}, "inbound_relationships" => { "film_actor" => [{ "source_column" => "actor_id", "referenced_column" => "actor_id" }] } }, "address" => { "direct_fields" => [{ "address_id" => "smallint unsigned" }, { "address" => "varchar(50)" }, { "address2" => "varchar(50)" }, { "district" => "varchar(20)" }, { "city_id" => "smallint unsigned" }, { "postal_code" => "varchar(10)" }, { "phone" => "varchar(20)" }, { "location" => "geometry" }, { "last_update" => "timestamp" }], "primary_key" => ["address_id"], "outbound_relationships" => { "city" => [{ "source_column" => "city_id", "ref

Comments URL: https://news.ycombinator.com/item?id=33862793

Points: 1

# Comments: 0