Asana

Asana custom field GIDs are long numeric strings. When you pass them as nested keys in HTTPie’s bracket syntax, HTTPie sees a numeric key and assumes you’re building an array, then tries to allocate memory up to that index. With a 16-digit GID, that’s enough to OOM the process. This breaks: https --session pat PUT https://app.asana.com/api/1.0/tasks/1208765432100001 \ data[custom_fields][1205432109876543]="1205432109876544" HTTPie reads 1205432109876543 as an array index and tries to build a sparse array of that size. It never gets to make the request. ...

Asana’s rich text API doesn’t use standard HTML. It accepts a strict subset with specific rules: only certain tags are allowed, nesting rules differ from what browsers tolerate, and the format is closer to XML than HTML, meaning unclosed tags, loose attributes, or anything outside the allowed set will be rejected or silently mangled. LLMs tend to produce plausible-looking but subtly wrong output here. They’ll use tags Asana doesn’t support, nest things incorrectly, or generate valid HTML that Asana’s parser rejects. ...

When I shipped mcp-server-asana 1.1.0, the headline addition wasn’t the six new Asana tools (task dependencies, stories, subtasks, project sections). It was prompts. In the MCP protocol, prompts and tools are distinct concepts. Tools are individual actions an LLM can invoke: create a task, add a dependency, fetch a comment. Prompts are predefined conversation templates: parameterized, reusable starting points that an MCP host can surface directly to users. The task-summary prompt added in 1.1.0 illustrates the difference. Instead of leaving the LLM to figure out what to fetch and how to present it, the prompt defines a scaffold: current status, key updates, blockers, next steps. The LLM gets structure, not a blank page. ...