Score academic and professional writing against published criteria with three reference models.
Scored across 4 tools
Each tool has a distinctly different purpose: evaluate_text scores a text, get_criteria returns the rubric, screen_text does a cheap pre-check, and verify_record looks up registered records. There is no overlap or ambiguity between them.
All four tool names follow a consistent verb_noun pattern in snake_case: evaluate_text, get_criteria, screen_text, verify_record. This makes the API predictable and easy to navigate.
With only four tools, the server is tightly scoped to its domain of text evaluation and record verification. Each tool serves a distinct step in the workflow, and the count feels appropriate for the service's purpose.
The tool surface covers the full lifecycle: understanding criteria (get_criteria), screening drafts (screen_text), scoring (evaluate_text), and checking published records (verify_record). There are no obvious gaps for the stated domain.
Score a text against published academic criteria. Use when a user wants to know how strong a paper, case report, thesis chapter or teaching material is, or wants a reviewable score before submitting it somewhere. Returns a 0 to 100 score, a per criterion breakdown, the divergence between three reference models and whether the work qualifies for a citable DOI record. Does not accept recipes, operational legal documents, workout plans or other how to instructions. This is not peer review and the score is not an accreditation. Crivum reads any language and answers in the language of the text, and the criteria were calibrated in Portuguese and English, so comparing results across languages is a reading nobody has measured yet. Requires an API key. Gatilho em português: "quero saber a nota do meu texto antes de submeter".
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Full text to score, in the original language. | |
| title | Yes | Work title. | |
| work_type | Yes | Work type key from get_criteria. | |
| evaluation_id | No | Caller-chosen id for idempotent re-calls. A new one is generated when omitted. | |
| academic_level | No | Academic level (T, G, E, M, D, P) or 'auto' to let Crivum infer it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does substantial work: it disclaims what the tool will not accept, clarifies that it is not peer review or accreditation, notes that it reads any language and answers in the text's language, flags the Portuguese/English calibration caveat, and requires an API key. It stops short of covering all operational behaviors, but the key non-obvious traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and use cases, and every major claim earns its place. However, the Portuguese trigger phrase and the language-calibration caveat add notable length; they are useful but could be tightened, so it is not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema and no annotations, the description is fairly complete: it explains what the return value includes, what inputs are excluded, language behavior, and authentication requirements. It does not give an example or detail the DOI qualification logic, but it covers the essential operational context an agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all five parameters including enums for work_type and academic_level. The description adds general context about scoring and language but does not add parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Score a text against published academic criteria.' It clearly distinguishes evaluate_text from siblings by focusing on evaluation with a reviewable score, whereas get_criteria, screen_text, and verify_record suggest retrieval, screening, and verification rather than scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance ('Use when a user wants to know how strong a paper... or wants a reviewable score before submitting') and strong when-not-to-use boundaries ('Does not accept recipes... This is not peer review and the score is not an accreditation'). It does not explicitly name sibling alternatives, which 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.
Return Crivum's public rubric by work type, the tier ladder, the thresholds, the minimum score for a citable record and what Crivum accepts and refuses, each with a version number. No API key required. Use before calling evaluate_text, or to show a user what a score decomposes into. Gatilho em português: "quais são os critérios da Crivum".
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that no API key is required and that results include version numbers, and it implies a pure read operation ('Return'). It doesn't mention rate limits or caching, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence is a dense list, but every item is informative. The second sentence adds authentication and usage context; the third provides a Portuguese trigger. There is no fluff, though the enumeration is slightly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers what is returned, the authentication requirement, and when to use it. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden. The description focuses on return values rather than parameters, which is appropriate. Baseline 4 for 0-param tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and precisely enumerates the resource and its contents: public rubric by work type, tier ladder, thresholds, minimum score for citable records, accept/refuse criteria, each with version numbers. It also differentiates from siblings by positioning itself as a pre-call for evaluate_text, so an agent can distinguish it from screen_text and verify_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states explicit use cases: 'Use before calling evaluate_text, or to show a user what a score decomposes into.' It also provides a Portuguese trigger phrase, which helps with localization. It does not explicitly list when-not-to-use alternatives, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a draft is ready before spending anything on it. Returns a 0 to 100 readiness reading, the suggested work type and up to six objective questions about what is still missing. Runs on a single cheap model and needs no API key, so it is the right first call when a user asks if a paper, case report, thesis chapter or teaching material is good enough yet. For the score that counts, with three reference models and eligibility for a citable record, call evaluate_text afterwards. Gatilho em português: "meu texto já está bom o suficiente".
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Draft to screen, in the original language. Long texts are trimmed, never refused. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it discloses useful operational traits: it runs on a single cheap model, needs no API key, and returns up to six questions. It also notes the Portuguese trigger phrase. It does not state whether the draft is persisted or explicitly confirm read-only behavior, but the 'before spending anything' framing implies 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-sentence but front-loaded with purpose and outputs, then usage guidance and alternative. The Portuguese trigger phrase and cost details earn their place, though the text is denser than strictly necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers what is returned (score, suggested work type, questions), when to use it, cost/auth, and the better alternative. No critical information for invoking it correctly appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, text, is already fully described in the schema (coverage 100%), including min/max length and trimming behavior. The description therefore adds little beyond high-level output context; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Check whether a draft is ready') and names concrete outputs: a 0-100 readiness reading, suggested work type, and up to six objective questions. It also explicitly contrasts with evaluate_text, which prevents confusion with a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when this tool is the right first call ('when a user asks if a paper... is good enough yet') and explicitly routes to evaluate_text when a citable score is needed. This gives an agent clear selection logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Crivum's published, citable records (title, authors, DOI when registered, tier and score). Pass exactly one of slug, doi or codigo to check one specific record, or omit all three to browse recent registrations. Rejects calls that pass more than one identifier at once, instead of matching either. No API key required. Gatilho em português: "esse trabalho já tem registro na Crivum".
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | Registered Crossref DOI. | |
| slug | No | Publication slug, e.g. from a crivum.org/p/ URL. | |
| limit | No | Page size when browsing (default 20). | |
| codigo | No | Compact code shown on the record, e.g. 'Crivum MB74'. | |
| cursor | No | Opaque pagination cursor from a previous call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals the rejection of multi-identifier calls, states that no API key is required, and includes a Portuguese trigger phrase. It does not cover not-found errors or response format details, but the provided behavior is meaningfully transparent for a lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core function, followed by usage modes, rejection behavior, auth, and a localization trigger. Each sentence earns its place, though the Portuguese phrase is slightly tangential to tool mechanics and could be seen as extra.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers return fields, invocation modes, rejection behavior, and auth requirements. The schema supplies pagination defaults and cursor semantics. The only notable gap is explicit handling of unknown identifiers or error responses, which is minor for a read-only verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by defining mutual exclusivity among slug, doi, and codigo, and clarifying that limit and cursor apply to browsing mode. This gives agents higher-level usage context the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('Crivum's published, citable records'), and enumerates the fields returned (title, authors, DOI, tier, score). It clearly distinguishes the single-record verification mode from the browse mode, and the focus on record verification separates it from sibling tools like evaluate_text and screen_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit operational guidance: pass exactly one of slug, doi, or codigo to check one record, or omit all three to browse. It also states that multiple identifiers are rejected. It does not explicitly name sibling tools as alternatives, but the when-to-use instructions for this tool's modes are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
evaluate_textget_criteriascreen_textverify_recordGenerate tailored quality criteria and scoring guides from your task descriptions. Refine objectiv…
Find AI-isms with evidence and fingerprint a writing voice from samples. 3 of 5 free.
Human-likeness scoring of AI text vs 12 real personality profiles; free tools + x402 paid tier
Loads your personal writing voice into any AI and scores how closely a draft matches it.
Add one secure layer between your agents and this server.
