doings-evidence-mcp

Server Quality Checklist

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

Latest release: v0.11.0
Disambiguation4/5
Most tools have clearly distinct purposes, such as critique_claim for research-intensive assessment vs. critique_org_text for user-facing text. However, can_we_say_this and make_client_safe both deal with safe wording, creating minor ambiguity.
Naming Consistency4/5
The majority follow a clear verb_noun pattern (e.g., analyze_org_argument, fetch_doings_document). Exceptions like can_we_say_this (a phrase) and think_with_evidence (slightly different) are minor deviations.
Tool Count5/5
With 15 tools, the set covers a broad domain of evidence-based consulting without being overwhelming. Each tool addresses a specific need, from argument analysis to evidence searching.
Completeness4/5
Core workflows are well-covered: claim analysis, evidence rating, internal and external searches, and text rewriting. Missing potentially useful features like document editing or report synthesis, but these are outside the stated scope.
Average 2.8/5 across 15 of 15 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 32 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations provided. The description mentions internal processes (e.g., evidence-aware critique) but fails to disclose side effects, authentication needs, or constraints. Behavioral traits beyond the listed features are unclear.
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 dense run-on sentence listing many capabilities. It lacks structure, making it hard to parse and not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, many sibling tools, no output schema), the description is severely insufficient. It does not explain return values, parameter usage, or how to choose among siblings, leaving the agent underinformed.
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 any of the 10 parameters. The agent gains no additional meaning beyond the raw schema, which is especially problematic for parameters like mode and strictness.
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 lists multiple capabilities (e.g., evidence-aware critique, argument mapping) but does not succinctly state a single verb-resource action. It is vague, using 'helps users think' without a concrete deliverable, making it hard to distinguish from sibling tools like critique_claim.
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 on when to use this tool versus siblings. It is labeled 'default user-facing thinking interface' but does not specify scenarios where alternatives like critique_claim or detect_solution_first_thinking would be more appropriate.
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?
No annotations provided, so description must disclose behavior. It only states the transformation but doesn't mention safety precautions, permission needs, or return format. Lacks depth for a mutating tool.
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?
Very brief (one sentence), but underspecified given 4 parameters. Conciseness is achieved at the cost of necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema, annotations, or parameter explanation, the description is far from complete. Agent lacks details on return values, error states, or required inputs.
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 coverage is 0% and description does not explain parameters (input, saferVersion, mainRisk, solutionFirst). Agent cannot infer how to use optional parameters or their impact.
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 purpose: converting internal critiques or rough claims into client-safe language. It specifies both input and output, distinguishing it from siblings like 'critique_claim' or 'rewrite_in_doings_voice'.
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 on when to use this tool versus alternatives. Siblings like 'can_we_say_this' or 'rewrite_in_doings_voice' may overlap, but description doesn't clarify when to choose 'make_client_safe'.
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?
No annotations are present, so the description must disclose behavioral traits. It describes the output categories but does not mention whether the tool is read-only, requires specific input formatting, or has side effects. The nature of mapping suggests a safe analysis, but this is not explicitly stated.
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 a single sentence listing many components, which is adequate but somewhat verbose. It front-loads the main verb but could be more concise by grouping categories or using bullet points. Still, it is not excessively long.
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 lack of output schema, no parameter guidance, and 15 sibling tools, the description is incomplete. It does not clarify what the tool returns or how to interpret the mapped categories, nor does it help the agent decide when to use this over other analysis 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%, meaning the parameter 'input' has no description beyond its name. The tool description does not explain what the input should contain (e.g., a full argument text, a sentence), its expected format, or provide examples. This leaves the agent guessing.
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 a specific verb 'maps' and lists concrete output components (symptom, diagnosis, assumed cause, etc.), making the purpose clear. It distinguishes from siblings like 'critique_org_text' or 'detect_solution_first_thinking' by focusing on mapping reasoning structure rather than critiquing or detecting patterns.
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 on when to use this tool versus siblings such as 'critique_org_text' or 'detect_solution_first_thinking'. The description does not specify prerequisites, context, 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?
No annotations provided, so description must fully disclose behavior. It mentions returning 'safer wording and caveats' but does not explain internal process, output format, 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?
Single sentence with no wasted words, but it is too brief to convey necessary detail. Structure is minimal; front-loading is fine but content is insufficient.
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?
For a tool with 10 parameters, no output schema, and several sibling tools, the description is far too sparse. It fails to explain modes, return values, or how it integrates with related 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 coverage is 0%, and the description provides no information about any of the 10 parameters. Each parameter's role and expected values remain 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?
Description clearly states it's a 'fast practical check' for safety of organizational claims or draft sentences, with safer wording and caveats. However, it does not differentiate from sibling tools like critique_claim or rewrite_in_doings_voice.
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 'fast practical check' implies quick assessment but lacks specifics on context 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?
No annotations are provided, so the description must fully disclose behavioral traits. It states the tool 'flags consulting-language risk and returns a narrative answer,' but does not clarify if it modifies input data or requires special permissions. The mention of a 'rewrite_safely' mode suggests possible mutation, but the description only says it 'chooses' among modes, not that it executes rewrites. This ambiguity reduces transparency.
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 concise at two sentences, but the first sentence could be more specific about the output. It front-loads the purpose but lacks structure; a bullet list of capabilities or examples would improve usability without being overly verbose.
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's complexity (10 parameters, no output schema, no annotations), the description is insufficient. It does not describe the format of the 'narrative answer', how parameters like strictness affect behavior, or what the tool returns. Agents lack critical context for correct 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?
The schema has 10 parameters with 0% description coverage, yet the tool description does not explain any parameter meanings beyond implicitly listing mode choices. It fails to compensate for the missing schema descriptions, leaving agents to guess the purpose of strictness, yearFrom, maxPapers, etc.
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 as a critique layer for rough consulting text, claims, pitch/RFP wording, and research questions. It specifies that it detects intent and chooses among sub-modes, and returns a narrative answer. However, it does not explicitly differentiate from sibling tools like critique_claim or analyze_org_argument, which have overlapping purposes, so it loses some 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?
The description provides no guidance on when to use this tool versus its siblings. While it mentions that the tool selects sub-modes automatically, it does not state prerequisites, exclusions, or when it is appropriate to invoke. With many similar tools available, this omission hinders selection.
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?
No annotations exist, so the description must carry the full behavioral burden. It mentions optional full-text escalation but does not explain the process, limitations, or outcomes for other parameters.
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 a single sentence, concise but overly sparse for a tool with 8 parameters. It could benefit from structured breakdown of key points.
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?
With 8 parameters and no output schema, the description is incomplete. It omits explanations for most parameters and fails to describe return format or pagination.
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 coverage is 0%, yet the description only mentions query and full-text escalation. It fails to explain crucial parameters like context, yearFrom, maxResults, includeAdjacentFields, maxFullTextPapers, and maxFullTextCharsPerPaper.
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 it searches OpenAlex and Semantic Scholar for research relevant to a claim or topic, with optional full-text escalation. This verb+resource combination is moderately specific, but it does not differentiate from sibling tools like search_doings_knowledge.
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 on when to use this tool versus alternatives (e.g., search_doings_knowledge). The description lacks context about prerequisites or best scenarios.
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 behavior. It only states the rewriting action but omits details like whether facts are preserved, any side effects, or required authorization.
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 but lacks necessary detail. It is concise but under-specified, missing guidance on when and how to use.
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's simplicity (2 params, no output schema), the description provides minimal context. It fails to fully inform an agent about inputs, output, or usage 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 coverage is 0%, and the description adds no meaning to parameters like 'context'. The description should explain parameter roles, especially since coverage is low.
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 rewrites text in a specific 'Doings voice', which is a distinct purpose from sibling tools. However, it could further clarify what 'Doings voice' implies.
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 on when to use this tool compared to alternatives like 'make_client_safe' or 'think_with_evidence'. Explicit usage context is missing.
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, but it only states the tool 'Flags' something without explaining what that means in terms of output (e.g., boolean, list, text) or side effects. It does not mention safety, reversibility, or auth requirements.
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 sentence that directly states the tool's purpose, with no filler words. It is appropriately concise but could benefit from slightly more detail without becoming verbose.
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 simple input and lack of output schema, the description is incomplete. It does not specify the return format or behavior (e.g., does it return a boolean, a flag, or a score?). Users would need additional context to use the tool correctly.
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 one parameter 'input' (string, minLength 5) with 0% coverage in description. The description gives a hint that input is a draft but no details on format, expected content, or how it relates to the flagging. The description adds minimal meaning beyond the schema.
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 verb 'Flags' and clearly identifies the specific pattern it detects: jumping to an organizational solution before establishing problem, evidence, and causal mechanism. This distinguishes it from sibling tools like 'analyze_org_argument' or 'critique_org_text' which focus on different aspects.
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 on when to use this tool versus alternatives. The implication is for detecting solution-first thinking in drafts, but no explicit when-to-use, when-not-to-use, or comparisons with siblings 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?
The description discloses the heuristic and evaluation criteria, providing some insight into behavior. However, with no annotations, it fails to disclose whether the tool is read-only, idempotent, or has side effects. The disclosure is adequate but not thorough.
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 efficiently conveys the purpose and criteria. No extraneous 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 description lacks details about the return value or output format, which is critical for a rating tool. It also does not differentiate from similar sibling tools. Given the lack of output schema, the description should provide more context about what the agent can expect.
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 parameters (claim, context, papers) are not explained in the description. The listed criteria (study type, causal strength, etc.) are not mapped to specific parameters, leaving the agent to guess how they relate. Schema has 0% coverage, so the description should compensate but does not.
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 rates evidence quality and lists the criteria used (study type, causal strength, etc.). However, it does not differentiate from sibling tools like critique_claim or classify_claims, which may have overlapping functionality.
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 on when to use this tool versus alternatives, nor are there any prerequisites or exclusions mentioned. The agent must infer usage from context alone.
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 full burden for behavioral disclosure. It only states the action without specifying behaviors like return format, handling of long text, or side effects. This is minimal 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?
Single sentence front-loaded with the core verb and resource. No redundancies or fluff. Every word contributes to purpose.
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 lack of output schema and zero parameter descriptions, the tool description should explain return values and usage details. It does not, leaving significant gaps for the 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?
Schema description coverage is 0% and the tool description does not add meaning beyond the schema. The 'claimTypes' parameter is mentioned in the output but not explained as an input filter. No details on 'text' format or constraints.
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 extracts and classifies claims from text into five specific types: causal, normative, diagnostic, descriptive, or prescriptive. This verb+resource+categories structure is unambiguous and distinguishes it from siblings like 'critique_claim'.
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 on when to use this tool versus alternatives (e.g., 'critique_claim' or 'detect_solution_first_thinking'). The agent must infer from the name alone. No exclusions or prerequisites mentioned.
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 full burden. It discloses main behaviors (fetch, extract, optional claim processing) but omits side effects, permissions, or failure modes. Adequate but not deep.
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?
One sentence, 22 words, front-loaded with the main action. Efficient but could be slightly more structured for readability.
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?
For a tool with 13 parameters and no output schema, the description omits return values, prerequisites, error conditions, and limitations. Incomplete for the complexity level.
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 descriptions coverage is 0%. The description hints at parameters like classifyClaims and validateHighRiskClaims but does not explain individual parameters or their defaults/enums.
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 fetches a document by URL, extracts text, and optionally classifies/audits/validates claims. It distinguishes from siblings like 'audit_doings_document_claims' by being the fetch+extract step.
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 vs alternatives like 'classify_claims' or 'audit_doings_document_claims'. The description only lists actions without context for selection.
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?
No annotations are provided, so the description bears full burden. It mentions searching via Microsoft Graph and the nature of documents, but lacks disclosure of side effects, limitations (e.g., pagination, read-only nature), or any behavioral traits beyond the source characterization.
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 short sentences with no redundancy. It front-loads the action and resource in the first sentence and adds distinguishing context in the second, making it concise and efficient.
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?
With no output schema and minimal parameter descriptions, the description fails to cover return values, behavior, or enough context for a search tool with three parameters. It lacks details on sorting, filtering, or results format, 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?
Schema coverage is 0%, and the description adds no parameter-specific information. The parameter names 'query', 'maxDocuments', and 'fetchTopDocuments' are somewhat self-explanatory, but 'fetchTopDocuments' remains ambiguous, and the description does not clarify any parameter 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 states the tool searches Doings SharePoint knowledge via Microsoft Graph, clearly identifying the verb 'searches' and resource 'Doings SharePoint knowledge'. It also distinguishes from the sibling 'search_research_evidence' by noting internal documents are treated as experience/IP, not academic evidence.
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 for internal knowledge searches and contrasts with academic evidence, but does not explicitly state when to use this tool vs alternatives like 'search_research_evidence' or provide when-not-to-use scenarios.
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 core behavior (auditing claims, citation markers, lacking support, optional validation) but omits side effects, permissions, or limitations (e.g., text size constraints, API costs for validation). The basic functionality is clear but not deeply transparent.
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 23-word sentence that efficiently covers the core function and optional feature. However, given the tool's complexity (13 parameters), a more structured description (e.g., listing main actions) could improve readability without adding much bulk.
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 is too brief for a tool with 13 parameters, 0% schema coverage, and no output schema. It fails to explain the validation parameters or the output format (e.g., what an audit produces). The agent needs more context to use the validation features correctly.
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. It mentions two input sources (url or text) and optional validation, but fails to explain the many validation parameters (e.g., validationYearFrom, validationMaxPapers, validationRedTeamMode) or their relationships. This leaves the agent underinformed about how to configure the 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 tool audits SharePoint document text or raw text for research-checkable claims, citation markers, claims lacking explicit source support, and optionally runs research validation. This distinguishes it from sibling tools like classify_claims (classification) and critique_claim (single claim critique).
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 for auditing documents with claims but does not explicitly state when to use this tool versus siblings (e.g., critique_claim for individual claims, classify_claims for classification). No exclusion criteria or alternatives 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?
Without annotations, the description carries full burden. It states the tool compares and flags, but lacks details on side effects, authentication needs, or output format. Sufficient for a basic understanding 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded with the action. However, it could benefit from structured mentions of parameters or usage to improve clarity.
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 4 parameters, no output schema, and no annotations, the description is incomplete. It doesn't explain return values, parameter details, or behavioral traits, leaving agents with 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?
Schema coverage is 0%, so the description must explain parameters. It mentions 'topic or claim' but doesn't clarify the role of 'claim' (optional) or 'context' and 'maxDocuments'. The description adds minimal value beyond the schema.
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 compares a topic or claim with Doings SharePoint knowledge and flags gaps, using a specific verb and resource. It distinguishes itself from siblings like search_doings_knowledge by focusing on identifying material needing review.
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?
No explicit guidance on when to use this tool versus alternatives. The mention of 'flags where internal material needs research review' gives context, but no exclusions or comparisons to sibling tools like audit_doings_document_claims.
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?
The description discloses key behaviors: default open-access full-text escalation, claim decomposition, level-of-analysis checks, etc. However, with no annotations, it should ideally specify potential side effects, permissions, or what happens when full-text is unavailable. The listed components add context but lack completeness.
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 highly concise: three sentences that succinctly capture purpose, components, and sibling differentiation. No redundant 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?
Given 9 parameters and no output schema or annotations, the description is insufficient. It lacks parameter descriptions and return value information, making it incomplete 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.
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. It gives high-level process components but does not explain individual parameters like 'strictness', 'yearFrom', or 'fullTextMode'. This leaves the agent without crucial guidance on parameter usage.
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 critically assesses an organization-design or transformation claim against research, with specific verb and resource. It also distinguishes from the sibling 'critique_org_text' for user-facing wording, eliminating confusion.
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 this tool (assessing claims against research) and explicitly directs to use 'critique_org_text' for user-facing wording. However, it does not mention when not to use it or differentiate from other siblings like 'classify_claims' or 'search_research_evidence'.
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:

[![doings-evidence-mcp MCP server](https://glama.ai/mcp/servers/Marcwarn/doings-evidence-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Marcwarn/doings-evidence-mcp)

Score Badge

Copy to your README.md:

[![doings-evidence-mcp MCP server](https://glama.ai/mcp/servers/Marcwarn/doings-evidence-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Marcwarn/doings-evidence-mcp)

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/Marcwarn/doings-evidence-mcp'

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