Content
67%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The content is a solid, executable runbook: every phase has concrete CLI commands, the connection state machine is handled with explicit polling and error paths, and the structure is easy to navigate. Main weaknesses are padding (a content-free overview tree, empty table cells, marketing background), an undefined 'Step 2' reference, and no per-action parameter guidance.
Suggestions
Fix the dangling 'skip to Step 2' references (lines 68 and 82) by either numbering the sections or replacing with 'skip to Searching for actions'.
Delete the 'Anymail Finder Overview' stub tree and the marketing sentence, and either fill the actions table's Description column (e.g. input hints for find-email-by-linkedin-url) or drop the column.
Trim the garbled 'Agent Types' aside to one line, e.g. 'Use --clientName matching your harness (claude, codex, warp, windsurf) so tooling is tuned to it.'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The bulk of the body is command-dense and efficient, but it carries several unnecessary elements: the 'Anymail Finder Overview' stub tree ('Search / Search Result / Account') with no content, a marketing-style background sentence ('It's used by sales teams, marketers, and recruiters'), six 'Popular actions' rows with an empty Description column, and a rambling 'Agent Types' aside. This fits anchor 3 ('mostly efficient but includes some unnecessary explanation') better than 4, where over-explanation would be isolated and minor. | 3 / 5 |
Actionability | Concrete, copy-paste-ready commands cover every phase: 'npm install -g @membranehq/cli@latest', 'membrane connection ensure "https://anymailfinder.com/" --json', 'membrane action run <actionId> --connectionId=CONNECTION_ID --input '{"key": "value"}' --json', plus a flag table for proxy requests. Minor gaps keep it at anchor 4 rather than 5: the 'Popular actions' table's empty Description column leaves the agent without parameter details (mitigated only by the pointer to 'inputSchema' from action list), and 'membrane login --tenant --clientName=<agentType>' is never explained. | 4 / 5 |
Workflow Clarity | The setup sequence (install → login → connection ensure → poll states → action list → action run) is clearly laid out with real checkpoints: '--wait' long-polling until state leaves BUILDING, explicit handling of CLIENT_ACTION_ERROR states with clientAction fields, and re-polling after user action. It is not 5 because 'If the returned connection has state: "READY", skip to Step 2' references a 'Step 2' that is never defined anywhere in the document, breaking the sequence's navigation. | 4 / 5 |
Progressive Disclosure | The body (~145 lines, no bundle files present) is organized into clearly headed sections (Install, Authentication, Connecting, Searching, Running, Proxy, Best practices) with a single one-level-deep external pointer (official docs URL) and no nested references. It is not 5 because the ~145-line single file inlines reference-style material (the full proxy flag table and the actions table) that could live in separate files, and the empty overview tree is not a useful navigation aid. | 4 / 5 |
Total | 15 / 20 Passed |