iFreeWork — public content

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that the content is a personal bio page, with no detail on return format or the bilingual behavior of the response.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short phrases, front-loaded with the content summary, with no filler. The Russian duplicate of the title is harmless but adds no informational value for an English-reading agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only, parameter-free-in-practice retrieval with full schema coverage and no output schema, the description says enough to call it correctly. Only the lack of usage routing keeps it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single lang parameter is fully documented in the schema (enum, default, meaning). The description adds nothing about language selection, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names the resource ('About page') and enumerates what it contains: who the developer is, experience, stack, and working style, which cleanly separates it from siblings like get_contact or get_portfolio_item. No explicit retrieval verb, but the intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives such as get_contact or search_content. Usage is only inferable from the tool name and content description, so an agent gets no routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds the return format (full text as Markdown), which is genuinely useful given there is no output schema, but says nothing about lookup failure behavior or language fallback.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short, front-loaded sentences that waste nothing and put the return payload first. The appended Russian sentence is redundant for a tool whose schema is already bilingual, costing it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does cover the core return value, but for a tool with four optional identifier parameters it omits identifier precedence and behavior when the article is not found or the language is unavailable. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters in detail. 'Pass id, slug or url' merely restates three schema fields and gives no precedence rule when multiple identifiers are supplied, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Full text of one blog article as Markdown'), which clearly distinguishes it from list_blog_posts and search_content. It also discloses the response format up front. It stops short of naming an alternative sibling explicitly, so a 4 rather than 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies you fetch a single article after obtaining an id/slug/url from a list result, which is useful implied guidance. However, it never states when to prefer this over search_content or get_blog_post's sibling readers, nor any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the description's job is to add return-content context. It does that by naming the exact channels returned (Telegram, e-mail) and that sending instructions are included — meaningful disclosure given there is no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short and front-loaded: the returned content leads the sentence. The bilingual restatement is redundant for an English-speaking agent, but it is a minor tax rather than a structural flaw.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless, read-only tool with no output schema, the description supplies what is otherwise missing — the shape of the response (contact channels plus message-sending guidance). Nothing an agent needs to invoke it correctly is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. Schema coverage is 100% and additionalProperties is false, so no undocumented inputs can exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (the developer's Telegram and e-mail) and adds the scope of 'how to send a message', so an agent knows this is a static contact-info lookup. It stops short of explicitly distinguishing itself from get_about or send_message, which is the one thing that would make the boundary unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to call this versus alternatives. The phrase 'how to send a message' hints at a relationship with the send_message sibling, but the description never says 'use this to learn the contact channel, then call send_message' — the routing is left entirely to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds one behavioral fact beyond the annotations: the response is delivered as Markdown. It says nothing about auth needs, rate limits, error behavior for a bad slug, or fallback when an identifier is missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the return shape before the identifier guidance. The trailing Russian duplicate ('/ Полное описание работы') is pure restatement and earns no place in an English-facing decision, which keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by naming the format and payload ('Full case description ... as Markdown'). Combined with the four identifier parameters and the safety annotations, an agent has enough to call it correctly; only the identifier-selection nuance (which of id/slug/url to prefer) is left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters (id, url, slug, lang) are already documented in the schema, including the lang default and the 'English exists only for translated pages' caveat. The description only restates that id, slug or url may be passed and omits lang entirely, so it adds little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Full case description of one project'), clearly a single-item fetch rather than a listing, which implicitly contrasts with list_portfolio/get_service. It does not name a sibling alternative, but the singular scope is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Pass id, slug or url' implies this is used after obtaining an identifier from a list result, which is useful implied guidance. However, there is no explicit when-to-use/when-not statement or mention of alternatives such as list_portfolio or search_content, leaving routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and non-openWorld, so the safety profile is fully covered. The description adds the useful fact that the payload is the full page text in Markdown, but says nothing about error behavior for a bad id/url, missing pages, or language fallback.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short and front-loaded: return format first, then identifier guidance. The bilingual duplication ('/ Полный текст услуги') is redundant for an agent reading English, but the whole description is still only two sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with no output schema and full schema coverage, the description is mostly sufficient, and it does state the Markdown return format. However, with required parameters = 0 it never clarifies that at least one of id/slug/url must be supplied, nor what happens if none is given — a real gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so id, url, slug and lang are already documented in detail (including the lang enum and the 'from a list result' provenance). The description adds only the OR-relationship between id, slug and url, and omits lang entirely; baseline 3 is correct when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: retrieving the full text of one service page, plus the return format (Markdown). This is clearly distinguishable from list_services and get_blog_post. It stops short of explicitly naming a sibling, so a 5 is not warranted.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says which identifiers to pass but never states when to use get_service rather than list_services or search_content. There are no exclusions, prerequisites, or alternative-tool routing, so the agent must infer usage entirely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered without the description. The description does add one genuinely non-structured trait — default sort order (newest first) — plus confirmation of pagination, but says nothing about page-size limits, total counts, or empty-result behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The English clause is tight and front-loaded, but the appended Russian duplicate ('/ Статьи блога.') adds no information for the calling agent and is pure filler. Useful content is present but the sentence is fragmented rather than well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only, zero-required-parameter list tool with annotations covering safety, this is close to adequate, but the description omits how lang affects results and gives no hint of the returned item shape despite there being no output schema. An agent can call it, but with avoidable ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 25%, so the description should compensate; it explains category filtering and pagination but never mentions the lang parameter or its effect on listing. The lang enum is documented in the schema (ru default, en only for translated pages), which partially offsets the gap but leaves page/per_page undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Identifies the resource (blog articles) and its scope (newest first, filterable, paginated), which is more specific than a bare name restatement. It does not explicitly distinguish itself from the sibling get_blog_post, but the plural/listing framing makes the distinction largely inferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus get_blog_post or search_content, nor any exclusions. The mention of category filtering and pagination hints at capability but provides no selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds one behavioral fact beyond the annotations — that results are paginated — but says nothing about default page size, ordering, or what happens with an unknown category/tag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense semicolon-separated sentence plus a short bilingual restatement; filters and pagination are front-loaded and nothing is wasted. The Russian clause is redundant rather than harmful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter read tool with no output schema and only 40% schema coverage, the description covers the core capability but omits language selection, paging defaults, and the fact that category accepts an id, slug or title. Adequate but with identifiable gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 40%, so half the parameters (tag, page, per_page) are documented only by name and type. The description compensates partially by naming category and tag as filters, but adds no format or constraint detail beyond the schema's own category/lang descriptions, and never mentions lang or paging semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (completed portfolio projects) and the fields returned (category, tags, summary), which cleanly separates it from list_blog_posts, list_services and the singular get_portfolio_item. It does not name a sibling explicitly, but the resource noun makes the distinction unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by listing the available filters (category slug/title, tag) and noting pagination, so an agent can infer this is the browsing/collection endpoint. However, it never says when to prefer this over get_portfolio_item for a single item or search_content for free-text queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond that — nothing about what the list contains, ordering, or how it relates to get_service.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short and front-loaded, with the category enumeration doing the informative work. The duplicated Russian string is a minor space cost but consistent with the bilingual tooling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-parameter read-only list with full schema coverage and no output schema, the description is adequate to invoke the tool. It is not sufficient to place the tool correctly among its siblings (get_service, search_content), which is the remaining meaningful gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single lang parameter is fully documented with its enum and default, so the schema carries the burden. The bilingual 'Список услуг' tail hints at the ru/en duality but adds no syntax or format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource clearly ('Services offered') and enumerates the service categories returned. It does not, however, distinguish this list operation from the sibling get_service (singular), so an agent can't tell from the text alone which one returns the catalog vs. a single item.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of when to prefer get_service instead, and no prerequisites. The agent is left to infer that this is the catalog-listing entry point from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety needs no restating. The description adds value beyond them by disclosing the return shape ('ranked pages with snippets and urls'), which matters because there is no output schema. It says nothing about ranking factors, pagination, or match behavior (e.g., fuzzy vs exact).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The English sentence is tight and front-loads the verb, scope and return shape with no filler. The trailing Russian restatement ('Поиск по сайту') duplicates the information for no functional gain, which is the only waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully covers what comes back, and annotations cover the safety profile, so an agent has enough to invoke it. The main residual gap is the undocumented limit parameter and any guidance on choosing this tool over the list_* siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, with lang, query and sections documented in the schema while limit carries no description. The description only echoes the section names already present in the enum and adds no syntax, matching or defaulting guidance, so it does little beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Keyword search across About, Services, Portfolio and Blog') and even scopes the return shape ('ranked pages with snippets and urls'). This clearly separates it from the get_*/list_* siblings, which retrieve known items rather than search by keyword.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the word 'search' and the section list, so an agent can infer this is the tool for unknown-location lookups while get_*/list_* are for known items. However, no explicit when-to-use, when-not-to-use, or alternative is named, leaving the routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes beyond the annotations by disclosing the approval precondition (confirmed_by_user=true), the rate limit, and the duplicate-suppression behavior. This adds real operational context on top of openWorldHint/idempotentHint, letting the agent anticipate failure modes rather than infer them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The English content is front-loaded and tight, but the appended Russian sentence restates the same information, which is redundant for an agent consuming the tool. The duplication wastes space without adding meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 5 fully-documented parameters, the description still covers everything an agent needs: the approval gate, idempotency, and rate limiting. Nothing material is missing for successful invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description confirms that the approved email is the reply-to address, but adds little syntax or constraint detail beyond the already-documented schema fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Delivers a message to Andrey Zubar') and pins down the mechanism ('same mechanism as the contact form on the home page'). All nine siblings are read-only getters/listers, so this write-to-owner tool is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context: it requires prior human approval of the exact text and reply-to email, and notes it is rate limited with duplicate suppression. It does not explicitly name alternatives, but no sibling performs a comparable action, so the omission is minor.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.