Loading ToolBench
MCP server for career.habr.com, driven by a browser session cookie. Exposes generic tools to interact with Habr career site forms and pages without write API by reading server-rendered HTML forms.
Three tools with clear, domain-specific descriptions (194 - 280 chars, within baseline 34 - 392). All have input schemas with types. However, parameter descriptions are sparse or missing entirely. habr_get and habr_form lack descriptions for their 'path' parameter. habr_submit's 'data' parameter is described but 'method' lacks guidance on valid values. No output schemas documented. Error handling is minimal, tools return raw HTTP status and body text rather than structured recovery guidance. Naming is verb-forward (habr_get, habr_form, habr_submit) but domain-specific prefixes reduce clarity for LLMs unfamiliar with Habr. No enum constraints on method parameter.
Schema of the forms on a page: action, method, field names, select options. The main way to learn what an edit page accepts, instead of reading the whole HTML. Some pages are rendered by Vue — their fields come from data-ssr-state and are appended below the HTML forms.
GET a page or JSON endpoint of career.habr.com. path looks like '/settings/profile'. HTML is stripped of script/style/svg — they are 97% of the page bytes (fonts, mixpanel) and carry no meaning. raw=True returns it untouched: needed when grepping through JS chunks.
Submit the form found on `path`, overriding only the fields given in `data`. Every other field is resent with its current value, otherwise Rails blanks it. Action and method come from the form itself; Vue fields (skills, specializations, languages, dates) are filled in automatically. Field names come from habr_form, e.g. habr_submit("/profile/specialization", {"user[salary]": "500000"}). The reply starts with SAVED / NOT SAVED: <reason> — Rails returns validation failures with HTTP 200, so the status code alone cannot be trusted. If the page has no form (action links such as deleting an experience entry), `data` is sent as-is to `path` with the given method.
Parameter descriptions incomplete. 'path' parameter in habr_get and habr_form lacks description. 'method' in habr_submit has no description or enum constraint (POST|PATCH|PUT|DELETE). LLMs cannot infer valid values.
No output schema documented. Tools return raw HTTP responses (status code + body text) without structured field definitions. LLMs cannot plan downstream calls or extract specific data reliably.
Error handling returns raw HTTP status and body text. No recovery guidance. 'NOT SAVED: <reason>' in habr_submit is a start, but habr_get and habr_form offer no actionable error messages. LLMs cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
No enum constraint on 'method' parameter in habr_submit. Defaults to POST but accepts any string. LLMs may pass invalid HTTP methods.
Credentials (HABR_COOKIE) injected via environment variable, which is correct. However, no audit logging of tool calls. Agent actions are not traceable for compliance or debugging.