mcpforwork

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but a few pairs like hunt_plan/source_playbook and parse_cv/preview_url_import could be confused without careful reading. However, the detailed descriptions effectively disambiguate them, and the application workflow tools each have specific roles.
Naming Consistency4/5
The majority of tools follow a verb_noun pattern (e.g., get_profile, create_profile, submit_asset), but some read-only data tools use noun phrases (e.g., pipeline_stats, autopilot_queue, ats_coverage_check, profile_gaps) and a few use less standard verbs (preview, hunt, check, request). Overall, the naming is readable and mostly consistent.
Tool Count2/5
With 41 tools, the surface is very large and exceeds the threshold for 'too many'. The domain is broad, but the granularity exposes many fine-grained workflow steps (e.g., confirm_submitted, record_outcome) that could be grouped into higher-level tools, making the set overwhelming for agents.
Completeness4/5
The tool surface covers the full lifecycle: profile creation/import, job hunting, match management, drafting, application execution, and GDPR data rights. Minor gaps exist, such as no dedicated tool to get an application's current status and no update/delete for achievements, but core workflows are well covered.
Average 3.7/5 across 41 of 41 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 99 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the output type (a local file path) and offers no insight into side effects, error handling, or conditions under which the path might be invalid or temporary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It lacks the verb and actionable detail needed to be useful, so it does not earn its place as a meaningful specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and an output schema, the description provides minimal context. It fails to clarify the tool's overall behavior, how the asset_id is used, or what conditions might cause the call to fail, leaving the agent ill-equipped to handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (asset_id) with no description, and schema coverage is 0%. The description does not mention the parameter at all or explain how to supply the asset identifier, leaving the agent without guidance on how to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions the asset and the purpose (form uploads), and the tool name implies fetching a file path. However, it is phrased as a noun phrase ('A local file path...') rather than a clear action statement, so the exact behavior remains somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a hint about the use case ('for form uploads') but provides no guidance on when to choose this tool over alternatives like submit_asset or get_assets, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It adds two useful behaviors ('stored drafts' and 'newest version first'), but it does not state whether the operation is read-only, how filtering by asset_type works, what happens when no drafts exist, or any other safety/response characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler or redundancy. However, its brevity sacrifices clarity and action orientation, so it is efficient in form but not fully effective in content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values do not need explanation, but the description lacks usage guidance, parameter semantics, and meaningful behavioral context for a tool among many asset/match siblings. This is not enough for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It does not mention finding_id or asset_type by name, nor does it explain their roles or the effect of the optional asset_type filter. The vague 'match' hint is insufficient for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('stored drafts for a match') and an ordering behavior ('newest version first'), but it is a noun phrase rather than an explicit action statement (e.g., 'Retrieves...'), so it lacks a clear verb. It also does not differentiate itself from siblings like get_asset_file or get_match.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_match or get_asset_file. The phrase 'for a match' hints at a relationship to finding_id, but there is no explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only reveals ordering ('best score first') but says nothing about read-only semantics, default limit, status filtering behavior, pagination, or error handling. The behavior is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it is a fragment rather than a structured sentence. It avoids fluff, but the brevity becomes under-specification, lacking essential information about parameters and usage. It is more minimal than effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no annotations, the description is incomplete. It does not explain the role of status or min_score, nor how limit interacts with result size. The output schema may define return fields, but the description leaves too much ambiguity for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the meaning of limit, status, or min_score. The schema provides names and defaults, but the description adds no value in clarifying parameter semantics, and the valid values for status are completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool returns scouted matches sorted by score ('best score first'). This clearly indicates a list operation and distinguishes it from siblings like get_match (single match) or approve_match/discard_match (actions). However, it is phrased as a noun fragment rather than a verb, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use list_matches versus alternatives. The description does not mention intended use cases, filters, prerequisites, or exclusions. It offers no context for selecting this tool over other list operations like list_profiles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses 'no DB' which implies no database persistence, but it doesn't explain what 'apply' does, whether it has side effects on external systems, or what 'pack data' entails. This leaves major behavioral ambiguities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief with no redundant words, but the first sentence is a noun phrase rather than an action-oriented clause, and the term 'playbook' is ambiguous. It would be clearer as an imperative sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a high-level purpose and one constraint, but it omits parameter semantics and usage context. Given the tool has an output schema, return values are covered, but an agent still lacks enough information to know exactly what inputs and side effects to expect, especially with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description doesn't mention the 'slug' or 'query' parameters. The phrase 'one source' hints at the slug, but 'query' is completely unexplained, and its default value offers no clue. The description fails to compensate for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as 'the full search + apply playbook for one source' and adds the 'Pack data only — no DB' qualifier, which clarifies its non-persistent nature. It uses a specific resource ('one source') and distinguishes it conceptually from sibling tools like 'hunt_plan' or 'list_sources', though it lacks an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any exclusions, prerequisites, or use cases. Sibling tools are not referenced, and 'playbook' is left undefined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits itself. It does not explain whether this tool creates a new profile, updates an existing one, overwrites data, or requires specific input formats. The statement only gives an intended outcome, not operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, effectively communicating the core purpose. However, it is arguably too terse given the need for more explanatory detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has three parameters, no annotations, and a minimal description, it is incomplete for safe invocation. Missing information includes side effects, when to use, and parameter semantics, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It only vaguely implies a writing sample is involved but does not clarify the roles of directives or profile_id, nor any constraints on writing_sample. This leaves the agent with insufficient parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Capture' with the resource 'user's writing voice', conveying the tool's core purpose. However, it doesn't explicitly mention that it sets a style profile or differentiate from sibling tools like create_profile or update_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion scenarios. It solely states the purpose without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Switch the active profile.' It does not explain what happens to the previous active profile, whether the change is reversible, persists across sessions, or requires specific permissions. This lack of detail leaves the agent to infer side effects, which is risky for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is easy to parse and front-loads the core action. Every word earns its place, with no redundant phrasing or filler. It is concise in the best sense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description omits crucial context about what 'active profile' means, how it relates to other profile tools, and whether there are any constraints or side effects. The description is too sparse to fully guide an agent in a context where many sibling profile-related tools exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (profile_id) with no description, and the tool description does not mention any parameters at all. With schema description coverage at 0%, the description fails to provide any meaning for profile_id beyond its type, leaving the agent unsure what value to pass or how it relates to the active profile.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch the active profile.' uses a specific verb ('switch') and a clear resource ('active profile'), making the tool's purpose immediately understandable. It distinguishes itself from sibling tools like create_profile, get_profile, and set_style_profile by focusing on changing the active profile rather than creating, reading, or styling one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, whether this should be called before other profile-related operations, or any context about what 'active profile' means. The description simply states the action without any usage protocol.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It discloses that items need a 'metric' and that the operation is an append, but it does not explain side effects, requirements, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single simple sentence, front-loading the action and constraints with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, one required complex object, no annotations, and an output schema not shown. The description leaves critical details about the item shape and profile_id unspecified, making it insufficient for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It clarifies that each item requires a 'metric' but does not explain the full structure of the items array or the optional profile_id parameter, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Append' with the resource 'achievements bank' and adds a constraint that each item needs a 'metric', clearly stating what the tool does and distinguishing it from sibling tools like record_outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies a use case (adding quantified wins) but does not mention any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the deterministic nature and the critical policy 'never stuff,' meaning it will not recommend adding false keywords. This provides valuable behavioral context, though it omits side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently presents the core purpose and outcome categories. The line break and colon list improve readability without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's logic and behavioral policy, and an output schema exists, but it lacks parameter semantics and usage prerequisites. For a two-parameter check tool, this leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention finding_id or asset_id at all. The agent cannot infer what these parameters represent, making this a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a deterministic check comparing the posting's keywords against a stored draft, and enumerates three outcome categories. This specific verb+resource pair distinguishes it from siblings like profile_gaps, though the terms 'posting' and 'draft' could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The phrase 'deterministic check' implies a verification step, but no alternatives or exclusions are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Inspect' implies a read-only operation, but it does not disclose what happens if the id is not found, whether it returns a full match or a summary, or any other behavioral traits. Minimal disclosure beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundant words. It is front-loaded and economical, which is appropriate for a simple lookup tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and an output schema exists, the description lacks essential context about when to use it relative to sibling tools and provides no parameter semantics. It is technically complete for a minimal get-by-id, but leaves the agent to guess details like how the id relates to a 'finding'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only says 'by id', which merely restates the parameter name 'finding_id' without adding any semantic meaning. It does not explain what a finding id is, how to obtain it, or any constraints beyond the schema's integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Inspect' and clearly identifies the resource (one scouted match) and lookup method (by id). It distinctly differentiates from sibling tools like list_matches (listing multiple) and approve/discard_match (mutating).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies you should use this tool when you have a specific finding id and want to inspect that match. However, it provides no explicit guidance on when to use this vs alternatives, nor any when-not-to-use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful content context (the brief's structure) and a critical constraint ('Only claim what the facts_inventory proves'), but does not explicitly disclose side effects, authentication needs, or error behavior. This is typical for a read-only getter, but the description does not confirm it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that efficiently convey purpose and a key rule. The first sentence is slightly awkward with the ellipsis and all-caps 'YOU', but overall it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple getter with an output schema (presumably detailing the brief structure), the description doesn't need to explain return values. However, it lacks parameter semantics and explicit usage guidance, leaving gaps for an agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the two parameters (finding_id, asset_type). It mentions 'facts_inventory' but that is part of the output, not a parameter. The agent is left without any guidance on what values to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a structured brief containing job keywords, facts inventory, style, and honesty rules for drafting a CV/cover letter. This specific resource is distinct from sibling tools like get_profile or get_asset_file, and the intended use is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'YOU draft the cv/cover_letter from' implies the brief is to be used as the basis for drafting, but there is no explicit statement of when to call this tool versus alternatives, nor any exclusions or alternative tool names. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions that the tool 'feeds calibration' but does not disclose whether the action updates an existing application, is irreversible, or has side effects. The lack of detail on mutability or data handling is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action and includes the crucial enumeration of outcome values. Every word earns its place, with no irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description does not address when in the process to call this tool, what state the application must be in, or how it interacts with other application-related tools. It is minimal and leaves significant contextual gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning to the 'outcome' parameter by listing allowed values, but provides no explanation for 'application_id' or 'notes'. Parameters remain partially undocumented, leaving uncertainty about their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Record what happened') and enumerates the specific outcome values it accepts, distinguishing it from sibling tools like 'record_application' or 'report_apply_progress'. The mention of feeding calibration adds context about its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an outcome is known and needs to be recorded, but it does not explicitly explain when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The 'feeds calibration' note gives context but not clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that this is an opt-in crowd-learning report, suggesting a non-critical, voluntary action, and it defines the kind values. However, it doesn't disclose whether data is sent externally, if the action is a write that persists data, any required permissions, or potential side effects, leaving significant gaps for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose ('Opt-in crowd-learning') and immediately follows with the action and key kind values. It contains no redundant phrasing and every word contributes to understanding the tool's intent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and a modest output schema, the description covers the core action and some parameter semantics but leaves 'diff' unexplained and offers no guidance on when to use the tool. The output schema exists, so return values aren't needed, but the overall context is still incomplete for an agent to fully understand the tool's role and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to 'kind' by listing the allowed values (success, drift, break) and implies that 'source_slug' is the source being reported on. However, the 'diff' parameter is entirely unexplained, and the description doesn't clarify the format or purpose of that parameter, leaving a third of the parameters underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reporting what worked, moved, or broke on a source to improve the next pack version. It uses a specific verb ('report') and identifies the resource ('on a source'), with 'kind' values enumerated, which helps distinguish it from other reporting tools. However, it does not explicitly contrast with siblings like submit_findings or record_outcome, so it misses the highest bar for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While it says 'opt-in,' which implies voluntary use, it doesn't clarify conditions, prerequisites, or situations where another tool would be more appropriate. The sibling tools include other reporting and recording tools, but no comparison or exclusion is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals an important behavior: at consent level 0, the tool always returns "await_human" and shows the filled form, requiring a human to click Submit. This goes beyond a generic description by explaining the human-in-the-loop nature and the conditional response, though it does not detail other consent levels or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence) and front-loaded with "THE consent gate," but it uses unclear jargon like "await_human" and "consent level 0" without explanation. It is concise but sacrifices clarity, making it less helpful than it could be despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains one conditional behavior (consent level 0) but omits essential context: what application_id is used for, what summary does, what the return value looks like, and what happens at other consent levels. Given the tool's role in a submission workflow and the absence of schema descriptions, the description is incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain either parameter. It never mentions application_id (required integer) or summary (optional string), what they represent, or how they affect the request. The phrase "show the filled form" hints at displaying application data, but this is insufficient for an agent to correctly populate the arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: "Ask permission to move to submission." It also identifies the tool as "THE consent gate," which distinguishes it from related tools like confirm_submitted and record_outcome. The verb and resource are explicit and unique within the sibling set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in a submission workflow—"Ask permission to move to submission"—and provides a behavioral condition for consent level 0. However, it does not explicitly state when to use this tool over alternatives like confirm_submitted, nor does it mention exclusions or prerequisites beyond the consent level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a significant behavioral trait ('versions auto-increment') and indicates the content is a markdown draft. However, it omits other relevant details such as permissions, overwrite behavior, or error conditions, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the action, the object, the format, and a key behavior, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters, no annotations, and an output schema (which covers return values), the description still lacks essential context: parameter roles, usage prerequisites, and any side effects besides versioning. It is not complete enough for reliable invocation in diverse scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the 3 parameters. It hints that 'content' is markdown and that there is a 'match' (likely finding_id), but it does not explain asset_type or clarify each parameter's role. This is insufficient for an agent to confidently map inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Store'), a resource ('YOUR draft (markdown) for a match'), and a key distinguishing behavior ('versions auto-increment'). This differentiates it from sibling tools like get_asset_file (retrieve) and submit_findings (submit findings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The description only implies usage for storing a draft but does not mention exclusions or alternative tools, leaving the agent without clear decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions the human decision aspect and the consequence (materials/apply can proceed), but it does not explain side effects, reversibility, or any permissions needed. This is a significant gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and object. It efficiently conveys both the action and its purpose without padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations), the description is adequate but not complete. It lacks details about preconditions, the nature of the match being approved, and how the result is returned. The presence of an output schema reduces the need to describe return values, but behavioral context is still thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not mention the 'finding_id' parameter at all. The parameter name is somewhat self-explanatory, but the description adds no meaning or context about what ID should be passed, leaving the agent to infer it from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Approve a match (human decision)' and the purpose: 'so materials/apply can proceed.' This distinguishes it from siblings like discard_match and start_application, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'so materials/apply can proceed' implies the tool is used as a prerequisite step in a workflow, but there is no explicit when-to-use guidance or mention of alternatives. It does not say when not to use it or contrast with discard_match.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry disclosure. It reveals side effects (state update, dedup, audit) but does not detail idempotency, error handling, or any destructive potential. It gives partial transparency, which is decent but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the key condition, and every phrase adds value. It is concise without being under-specified to the point of uselessness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and two simple parameters, the description provides adequate 'when' and 'what' context but lacks parameter explanations and deeper behavioral details. It is workable but leaves room for misinvocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description makes no mention of application_id or evidence. It adds zero meaning beyond the raw schema, so the agent is left to infer parameter roles from names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states the tool is for use after human confirms submission, and it 'closes the loop' with specific actions (state, dedup record, audit). This goes beyond a tautology and distinguishes it from request_submit and submit_findings, though 'close the loop' is slightly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly sets a temporal condition ('AFTER the human confirms they clicked Submit'), providing clear context for when to invoke. It does not name alternatives or exclusions, but the sequential implication is enough for basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the server's response pattern ('next step, repair, or human-pause') and asserts it never submits, which is valuable behavioral context beyond the schema. However, it does not mention side effects, state changes, or permission requirements, so it's not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core action and outcome constraints. Every word contributes value—no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values are covered, but the description omits critical context: the meaning of observed and obstacle, the overall workflow of progress reporting, and any prerequisites or side effects. For a mutation-like tool with no annotations and undocumented parameters, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters with 0% description coverage. The description adds meaning by defining the status parameter's allowed values (ok | blocked | mismatch), but it leaves application_id, step_id, observed, and obstacle completely unexplained. The description only partially compensates for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports a step's outcome and lists the allowed statuses (ok | blocked | mismatch). It also distinguishes from submission by explicitly stating 'never a submit,' giving some differentiation from sibling tools. However, it does not explicitly differentiate from other reporting tools like report_playbook_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (reporting a step's outcome) and an explicit exclusion ('never a submit'). It implies usage during an application process but does not name alternative tools for other reporting scenarios, so it falls short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses an important behavioral trait: the URLs are to be opened by the agent in the user's browser, not the tool itself. However, it does not explicitly state that the operation is read-only or describe any side effects, though such inference is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core purpose and includes a helpful clarification about the URLs. Every word contributes value, and it is appropriately sized for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no params), no annotations, and the presence of an output schema, the description adequately covers the tool's purpose and the agent's expected behavior. It could be slightly more explicit about the format of the playbooks, but the output schema likely fills that gap, so this is not a major deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so the baseline is 4. The description adds meaning by introducing the concept of the 'active profile', which indicates an implicit state dependency that is not captured in the schema. This helps the agent understand that the tool operates on the currently selected profile.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's output: per-source search playbooks (URLs) for the active profile. It conveys the resource and the intended use, but it lacks an explicit verb like 'retrieve' or 'get' and does not explicitly distinguish itself from the sibling 'source_playbook' tool, though the 'active profile' scoping offers some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to obtain URLs for searching postings, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. Sibling tools like 'source_playbook' exist, but no exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses ordering (required first, progressive) and an interaction style (one gap at a time, never form-wall), but doesn't explicitly state whether it's read-only or what the response looks like, though an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with a clear first sentence and actionable second sentence. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description covers purpose, ordering, and interaction guidance. It could add an explicit read-only statement, but is otherwise sufficient for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is trivially complete. The description doesn't need to add parameter details; baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: exposing what's missing in a profile, with required items prioritized. It distinguishes itself from get_profile (current values) and update_profile (modification), though it lacks an explicit verb like 'list' or 'return'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Offers a usage pattern: present gaps one at a time when contextually useful, and never show a form-wall. However, it doesn't name alternatives or explicitly state when to use this over get_profile or resolve_field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the key behavioral consequence (never re-surfaced), but does not clarify whether the match is deleted, whether the action is reversible, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb, no fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core action is clear, but with no annotations and no parameter guidance, the description leaves the agent to infer that finding_id identifies the match. The optional reason parameter is unexplained. Output schema exists, so return values are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage and the description mentions none of the parameters (finding_id, reason). It does not explain what to pass, making parameter semantics weak.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'discard' with resource 'match' and adds irreversible consequence 'never be re-surfaced', clearly distinguishing it from sibling approve_match, list_matches, and get_match.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'human decision' implies it's for human-in-the-loop scenarios and the permanence ('never be re-surfaced') clarifies it's for final rejection, but no explicit alternative or when-not-to-use is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It conveys the key behavioral effect that the answer is persisted and will not be asked again, but it does not mention side effects, idempotency, or failure conditions. The output schema may cover return structure, but additional behavioral context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of thirteen words, front-loaded with the verb 'persist'. It is extremely concise and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with an output schema, the description covers the core functionality, use context, and effect. It is sufficient to guide invocation, though it could mention behavior on duplicate field_label entries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds context that the 'answer' is a screener answer, but does not explicitly explain 'field_label'. The parameter names are self-explanatory, giving baseline clarity, but the description does not fully clarify the meaning or expected format of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'persist' and the resource 'screener answer', with the intent 'never asked twice'. It distinguishes itself from sibling tools like check_seen by indicating this tool saves an answer rather than just checking status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'HUMAN-confirmed' implies the tool should be used only when a human has confirmed an answer, giving some usage context. However, it does not explicitly state when not to use it or mention alternative tools that might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does reveal key traits: the new profile is made active and the patch parameter contains intake fields. However, it does not mention permissions, error behavior, or conflict handling (e.g., what happens if the label already exists), which is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with a clear action, a parenthetical side effect, and a succinct explanation of the patch parameter. Every word earns its place, and it is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are presumably covered and the description need not elaborate. However, it omits semantics for the label parameter and provides no guidance on usage relative to update_profile or set_active_profile. The core creation behavior is described, but important contextual details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains `patch` as the intake fields with examples, which is helpful. However, it does not explain the `label` parameter at all, leaving one of two parameters undocumented. The description adds value for patch but not for label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a new profile' with a specific resource and adds a distinctive side effect 'made active' and 'return it'. This distinguishes it from sibling tools like update_profile and set_active_profile, which are for modification and activation respectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to create a new profile and make it active. It does not explicitly provide alternatives or exclusions, but the context is clear given the sibling tool names. It lacks explicit 'when not to use' guidance, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it works on 'any open state' and explains the future behavior with start_application. It does not explicitly mention reversibility or permissions, but the mention of a 'fresh session' implies a non-permanent closure. This is adequate for a simple state-transition tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and includes only relevant behavior. There is no wasted wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the main operation and one key follow-up behavior, which is useful for a simple tool with an output schema. However, it omits any explanation of the parameters and does not cover potential side effects beyond the start_application implication. This leaves some ambiguity for an agent deciding to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. It references 'an application' which implies application_id identifies which application, but it provides no details about how to find application_id or what the optional 'reason' parameter is for. This is a significant gap for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Close an application you decided not to pursue (any open state).' It uses a specific verb ('Close') and identifies the resource ('application'), and distinguishes itself from siblings like discard_match by focusing on the application lifecycle rather than match-level actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when you have decided not to pursue an open application. It also explains that a later start_application for the same match opens a fresh session, which clarifies the state after abandoning. It does not explicitly name alternatives, but the usage context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses a key behavior: idempotent per URL, meaning repeated calls are safe. It also explains the effect on the copilot's surfacing behavior. This adds meaningful context beyond the schema, though it does not mention potential error cases or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action and purpose, and every word adds value. The first sentence states what it does and why; the second adds a critical behavioral detail. There is no redundancy or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters and an output schema, but the description only partially covers the domain. It clearly explains the purpose and idempotency, and the output schema covers return values, but the lack of parameter semantics for 'notes' and 'method' leaves out information needed for full autonomous use. The simple nature of the tool means the description is adequate overall, but it is not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It only touches on two parameters: 'url' via 'Idempotent per URL' and 'channel' via 'any channel'. The parameters 'notes' and 'method' are not explained at all, leaving the agent guessing about their purpose and acceptable values. The parameter names are somewhat self-explanatory, but the description fails to add sufficient semantics for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Record') with a clear resource ('application submission') and explicitly states the purpose: to prevent the copilot from re-surfacing the posting. It also distinguishes this from sibling tools by emphasizing the HUMAN submitter and 'any channel', and adds the idempotent-per-URL trait, making it clear what this tool does and why it exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when the human has submitted an application (via any channel) and you want the copilot to stop surfacing the posting. It does not explicitly name alternative tools or give when-not-to-use guidance, but the purpose is specific enough to indicate when it is appropriate relative to related tools like start_application or record_outcome.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the is_active behavior, but it does not explicitly state that the operation is read-only or mention any side effects. The verb 'List' implicitly suggests a safe read, but more explicit disclosure would be better.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It delivers the essential action and a key output detail efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool with an output schema available, the description is complete. It covers the crucial is_active nuance, while the output schema handles return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add parameter-level meaning. Baseline for 0 params is 4, and the description does not need to compensate for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' plus a clear resource 'user's profiles', and it adds a distinguishing detail about the active profile (is_active=1). This differentiates it from sibling tools like get_profile or set_active_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies its use case (listing all profiles), but it does not explicitly mention when to use it over alternatives like get_profile. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds that JSON fields are parsed and that a specific profile can be requested, which is useful, but it doesn't disclose error behavior, edge cases (e.g., no active profile), or explicitly confirm read-only semantics beyond the verb 'Return'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource, includes the optional parameter behavior, and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return value details are covered there. This is a simple one-parameter read tool, and the description sufficiently explains the core selection logic. The phrase 'JSON fields parsed' is slightly ambiguous but not enough to lower the score further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional nullable profile_id with a title and no description, so the description compensates by indicating that omitting it returns the active profile and supplying it returns that profile. The null/default semantics are implied rather than explicit, but the single parameter is fairly self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and clearly identifies the resource: the active profile or a profile specified by profile_id. This distinguishes it from sibling tools like list_profiles (which lists all) and set_active_profile (which changes the active profile).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'active profile (or a given one)' establishes clear retrieval context and implies when to use the tool: when you need a single profile, not a list or a mutation. It doesn't explicitly name alternatives or exclusions, but the purpose is clear enough from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It discloses that the tool performs a partial update (not a full replace), and importantly that it may create a profile if none exists and profile_id is omitted. This gives useful behavioral context beyond the schema. However, it lacks details about validation, error behavior, or auth requirements, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the primary action and add the critical conditional behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, output schema present), the description covers the core behavior and the key profile_id nuance. It could be improved by noting what happens for invalid profile_id or empty patch, but overall it is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It clarifies the behavior and semantics of profile_id (optional, defaults to active profile, can trigger creation). However, it does not explain the structure or allowed keys of the patch object beyond implying a partial update, so the parameter semantics are only partially covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Apply a partial update') and the resource (profile). It also explains the behavior when profile_id is omitted, distinguishing it from create_profile (which explicitly creates) and set_active_profile (which sets active). This provides a specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to omit profile_id (to update active profile or trigger creation on the setup path). It implies the tool is for partial updates rather than full creation, but it does not explicitly exclude alternatives like create_profile for new profiles. This is clear context but lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It communicates the read-only nature by using 'Report,' but does not explicitly state side effects, permissions, or limitations. It adds context about 'scouted or applied' statuses, which is helpful, but more disclosure would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, followed by a clear actionable instruction. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description is complete. It tells the agent what the tool does and how to act on the results, providing sufficient context for invocation and follow-up.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'urls' parameter with no description, but the tool description clarifies that these are the URLs to check against known status. This adds meaning beyond the raw schema, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Report which URLs the copilot already knows (scouted or applied).' It uses a specific verb (report) and resource (URLs), and distinguishes the tool by indicating it checks known status. It also adds a directive for follow-up actions, which clarifies purpose further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by instructing to 'Only browse/apply the ones marked new.' This implies the tool should be used before actions to filter URLs. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds the 'Pack data only — no DB' note, which indicates the tool avoids database access and uses packed data. However, it does not detail auth requirements, pagination, or error behavior. This is moderate transparency, not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the core purpose, optional filters, and a behavioral note about data source. Every part contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with two optional parameters and an output schema. The description covers purpose and filter semantics, and with the output schema present, it need not explain return values. The behavioral note adds completeness. No critical information is missing for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that the `countries` and `sectors` parameters act as optional filters using tags, which directly maps to the schema properties. It does not specify the value format (e.g., ISO codes) but the semantic intent is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('List enabled sources') and the specific resource (sources), with an optional filter by country/sector tags. It distinguishes the tool from siblings like list_matches or list_profiles by focusing on sources. The phrase 'Pack data only — no DB' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when listing enabled sources, with optional tag filtering. It does not explicitly mention exclusions or alternative tools, but the intended usage is evident from the purpose statement. A missing explicit alternative recommendation keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'read' and 'the same read the dashboard shows,' clearly indicating a read-only, non-mutating operation. It does not mention potential caching or permission requirements, but for a simple stats read the key behavioral trait is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the essential purpose and a useful context sentence ('The same read the dashboard shows'). Every word earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (handling return value details), the description provides sufficient context: it names the categories, signals read-only behavior, and frames it as a dashboard-equivalent summary. No additional explanation is needed for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers them (100% coverage). The baseline for zero-parameter tools is 4. The description adds no parameter-specific meaning, which is appropriate since there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns pipeline counts for a status summary, enumerating specific categories (new matches, awaiting the human, submitted/verified, responses). This distinguishes it from sibling tools like list_matches or get_match, which provide detailed records rather than aggregate counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage via 'status summary' and 'the same read the dashboard shows,' indicating it is for overview/read purposes. However, it does not explicitly mention when to use this tool instead of alternatives or exclude it for detailed operations, leaving the guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool is deterministic, sources answers only from profile or saved answers, never invents, and falls back to asking the user. This provides strong behavioral transparency beyond the minimal schema info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the core purpose ('Deterministic answer') and packs in source, fallback, and a behavioral constraint. Every word earns its place; no unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (not detailed here), the description covers the core behavior well. It explains the decision flow (profile/saved answers, else ask_user) and the no-invention rule. However, it does not address edge cases like missing application_id or conflicting saved answers, and the parameter semantics are absent, leaving minor gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain any of the parameters (application_id, field_label, options, field_type). Although parameter names are somewhat self-explanatory, the description gives no guidance on how they relate to the resolution logic or how options and field_type affect behavior. This is a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb ('resolve') with a well-defined resource ('unpredicted form question') and source scope ('profile or saved answers'). It differentiates from siblings by emphasizing deterministic resolution and the 'never invent' constraint, which distinguishes it from save_form_answer or get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a deterministic answer is needed for an unpredicted form question. It also mentions the fallback ('otherwise ask_user') which gives context for handling unresolved cases, though it does not explicitly name alternatives or list exclusions. The context is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing the preflight checks (dedup gate, daily cap), the return of a step plan, and the exclusion of submit steps. However, it doesn't mention potential side effects on state (e.g., whether a session is created or if any record is marked) or what happens on preflight failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every clause adds value. It flows well and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to detail the response format, but it covers the key execution context: preflight steps, the step plan, the exclusion of submission, and the human-in-the-loop requirement. It could mention error handling or prerequisites (e.g., calling after approve_match), but overall it's sufficiently complete for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only implies that 'finding_id' refers to an approved match without explicitly defining the parameter. The context gives some hint, but it doesn't clearly state the format, source, or validation rules for finding_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('start') and resource ('supervised application session'), explicitly scoped to 'APPROVED match'. It also distinguishes itself from the sibling tool 'request_submit' by clarifying that the returned plan never contains a submit step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('for an APPROVED match') and explicitly names the alternative submission route ('request_submit is the only submission route'). It also implies that the agent should execute the step plan in the user's browser, providing clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that this tool writes, records provenance, and requires human confirmation, which is helpful context. However, it fails to clarify whether the mutation merges or overwrites existing fields, whether it is reversible, or what happens to previously stored fields—important behavioral gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and followed by a necessary usage warning. Every word earns its place; no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary purpose, the required sequence, and warns about the write nature. Given the output schema exists, return values don't need elaboration. However, it omits details about how existing profile fields are affected (merge vs replace), which is a notable gap for a tool that modifies an active profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does by explaining that 'url' is the source URL for provenance and 'fields' are client-LLM-extracted structured fields, giving examples (LinkedIn/GitHub/portfolio). While it doesn't specify the internal field object structure, it adds meaningful semantic context beyond the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Apply client-LLM-extracted structured fields'), the target ('the active profile'), and the additional provenance behavior ('recording the source url'). It also distinguishes this write tool from the sibling preview_url_import by explicitly saying this tool writes and must be called after preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage rule: 'Call ONLY after preview_url_import + human CONFIRM — this tool writes.' This clearly indicates when to use it and when not to (before preview/confirmation), effectively naming the alternative tool and the required sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It explicitly lists what is returned (version, tools, invariants) and implies a read-only, non-mutating operation. It is transparent about the tool's purpose, though it does not explicitly state 'no side effects'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that packs all necessary information without waste. It is concise and well-structured, using a colon to introduce the key return items.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter complexity and the presence of an output schema, the description is complete enough. It lists the key return categories (version, tools, invariants) and communicates the tool's role as a handshake, which suffices for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The description adds value by describing the response contents, which is the only relevant semantic information. It meets the baseline for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: returns server version, registered tools, and invariants for a handshake. It uses specific nouns and is distinct from all sibling tools, which are about profiles, assets, applications, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a handshake to be used at the start of a client conversation, and it mentions that the client must respect the invariants. This gives clear context for when to invoke it, though it does not explicitly list alternatives or say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool will dedupe, score against the profile, and persist the findings, giving a clear behavioral model. It also states a hard requirement for each finding (url + title). Since no annotations are provided, the description carries the full burden and does so adequately, though it omits error handling and permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The main action is front-loaded ('Ingest'), and every phrase adds value, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, and the description covers the purpose, processing steps, and a key validation rule. An output schema exists, so return values are not needed. Minor gaps remain around prerequisites (e.g., source existence), but these are common sense for the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides crucial semantic info for the 'findings' parameter by requiring at least url + title, which is not in the schema. The 'source_slug' parameter is implied by 'from a source', but not explicitly detailed. Given 0% schema coverage, this description partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Ingest') and resource ('postings/findings'), and explains the pipeline: deduped, scored, and persisted. The phrase 'YOU extracted' distinguishes it from URL-based import tools like import_from_url_findings, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent has already extracted postings from a source, as opposed to importing via URL. It provides clear context but does not explicitly name alternatives or state when not to use it, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only,' which is a key safety trait, and lists what data is included, offering transparency about the operation's scope. It does not mention potential large response size or auth requirements, but the read-only nature and content breakdown provide solid context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the regulatory context ('GDPR data portability'), immediately clarifies the output ('one JSON object'), and enumerates included data types. Every element earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (zero params) and has an output schema available, so the description need not explain return values. It covers the key aspects: what is exported, in what form, and that it is read-only. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides full coverage (100%). The description adds no parameter details, but none are needed. Baseline for 0 params is 4, and the description appropriately focuses on the output and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: exporting all stored data about the user for GDPR data portability. It specifies the verb ('export'), the resource ('everything stored about you'), and provides concrete content categories (profile, findings, applications, assets, audit trail), distinguishing it from sibling tools like get_profile or delete_my_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description sets clear context for use—GDPR data portability—and implies this is the comprehensive export tool for a full copy of user data. It does not explicitly mention alternatives or when not to use it, but the scope is unambiguous. This is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly states the tool is read-only and explains null policy behavior. It doesn't add details like auth or error conditions, but for a zero-parameter getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loads the core information, and every sentence adds value. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with an output schema, the description fully covers the necessary semantics: what the policy contains and the null case. It also signals the read-only nature, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is inherently covered. The description adds meaningful context by explaining what fields the policy contains and the meaning of null, exceeding the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the active autopilot policy (min_score, max_per_day, since when) including the null case. This is an informative, specific verb+resource description that distinguishes it from sibling tools like autopilot_queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use it: to check whether autopilot is on and what thresholds apply. It also clarifies that this is read-only via 'never here', but it doesn't explicitly name alternative tools for reading or modifying policies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only,' which is a key safety disclosure. It also explains the 'Empty when' condition, giving insight into runtime behavior. This is sufficient for a simple read-only queue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the key phrase 'L2 work queue,' with no filler. Every clause adds meaning: criteria, empty condition, and read-only behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema present, the description is complete. It covers what the queue contains, when it's empty, and safety status, without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, but the description fully explains what the tool returns and the meaning of the queue contents. This adds value beyond the empty schema, meeting the baseline 4 and exceeding it with rich semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the L2 work queue, defined by specific criteria (approved matches on auto_apply_safe boards, scoring at/above policy min, not dedup-blocked, no open application). This specific verb and resource scope distinguishes it from siblings like list_matches and get_autopilot_policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when the queue is empty (autopilot off or no safe board), implying the tool is for checking the autopilot queue. It doesn't explicitly mention alternatives or when-not-to-use, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: it is deterministic (regex-based, zero-LLM), returns candidate fields, treats None as unknown, and explicitly states it does not persist/write. This exceeds expectations by revealing its non-mutating nature and conservative fallback behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adds value: purpose, return semantics, and workflow guidance. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description covers operation, return conventions, and integration with update_profile. It fully answers how to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter cv_text has no schema description. However, the description implies its meaning via 'pasted CV text.' It clarifies that input is raw pasted text, which is sufficient given a single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Zero-LLM regex extraction of contact fields from pasted CV text.' It distinguishes from siblings by explicitly noting it does NOT write the profile, unlike update_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use logic: 'Does NOT write the profile: CONFIRM with the human, then call update_profile.' Also instructs to ask the human when None is returned, never inventing data. This is strong usage guidance versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses the tool is read-only, the server never fetches, the agent must open the URL and paste visible text, and it returns a specific shape. It also warns not to write and to confirm with the human, adding critical behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a sentence describing the mechanism, and a sentence about the result and next steps. Every sentence adds value with no redundant or vague phrasing. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two simple parameters and an output schema, yet the description covers the purpose, safety, workflow, and return shape by referencing parse_cv. It also differentiates from sibling tools and includes the necessary confirmation step, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must clarify the parameters. It explains that 'url' is the URL to open in the browser and 'page_text' is the visible page text to paste, which gives clear semantic meaning. However, it doesn't specify exact formatting requirements for page_text (e.g., raw vs sanitized), so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a read-only import preview for LinkedIn/GitHub/portfolio, with a specific mechanism (open URL in browser, paste visible text). It also distinguishes itself from the sibling import_from_url_findings by explicitly noting it does NOT write and requires confirmation first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use and when-not-to-use guidance: 'Does NOT write — CONFIRM with the human, then import_from_url_findings(url, confirmed_fields).' This names the alternative tool and clarifies that this is a preview step before a write action. Also states 'The server never fetches' to clarify the expected workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals irreversibility, the 5-minute token expiry, single-use nature of the token, and that deletion includes every table plus the account row. This is comprehensive for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it defines the operation, the two-step protocol, the token's validity and role, the irreversible consequence, and the safer alternative. The structure is front-loaded with the key labels and uses line breaks to separate the two call modes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive, human-consent-gated tool, the description is remarkably complete: it covers both invocation modes, the confirmation artifact, the deletion scope, the irreversibility, and a concrete alternative. The presence of an output schema reduces the need to describe return values, and the description leaves no major operational gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only shows an optional string confirm_token with default '', providing zero semantic coverage. The description fully compensates by explaining that omitting the token triggers a preview flow and including it triggers permanent deletion, and labels the token as a consent artifact that must come from the human.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a GDPR erasure tool with a specific two-step flow: it can either preview deletions and return a confirm_token, or permanently delete all user data when called with that token. It distinguishes itself from siblings by naming export_my_data as the safer alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call without a token (to get a summary and confirm_token), when to call with the token (to delete), and what to show the human. It also tells the agent to consider export_my_data first and never to invent a token, providing clear use vs. non-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcpforwork MCP server](https://glama.ai/mcp/servers/avivancos/mcpforwork/badges/card.svg)](https://glama.ai/mcp/servers/avivancos/mcpforwork)

Score Badge

Copy to your README.md:

[![mcpforwork MCP server](https://glama.ai/mcp/servers/avivancos/mcpforwork/badges/score.svg)](https://glama.ai/mcp/servers/avivancos/mcpforwork)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/avivancos/mcpforwork'

If you have feedback or need assistance with the MCP directory API, please join our Discord server