philosophy-mcp

Server Quality Checklist

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

Latest release: v0.1.3
Disambiguation5/5
Each tool has a clearly distinct purpose: search vs. list vs. get for different content types (thinkers, articles, glossary, syntheses), plus a general full-text search and corpus stats. No two tools have ambiguous boundaries.
Naming Consistency2/5
Tool names mix Portuguese and English ('buscar_pensador' vs 'search_artigos', 'get_artigo' vs 'listar_artigos'), use different verb prefixes ('get_', 'listar_', 'search_', 'buscar_'), and one tool uses snake_case English ('corpus_stats'). This inconsistency makes it hard to predict tool names.
Tool Count5/5
13 tools cover the main content types (articles, thinkers, glossary, syntheses) with search, list, and retrieval operations, plus a stats tool. The count is well-scoped for a philosophy reference server; each tool earns its place.
Completeness5/5
The tool surface provides full read-only access to the philosophy corpus: search across all sections, retrieve individual items, list all items, and get corpus statistics. No obvious gaps for the intended purpose of referencing philosophical content.
Average 3.6/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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, and the description only states 'full-text search' without detailing behavior like result format, pagination, or performance characteristics. For a search tool, this is minimal disclosure.
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?
Extremely concise: one sentence plus a clear parameter list. No wasted words, directly 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?
Covers the basic functionality and parameters, but lacks explanation of output (though output schema exists) and does not distinguish from similar sibling tools. Leaves the agent with incomplete decision support.
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%, but the description clearly explains each parameter: query is a search term, lang lists valid language codes with default, section lists valid filters. This adds meaning beyond the bare 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?
Clearly states 'Full-text search across the entire philosophy corpus,' indicating it covers all sections. However, it does not explicitly contrast with sibling tools like search_artigos, leaving some ambiguity about when to use this vs. specific section searches.
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 sibling tools such as search_artigos or search_glossario. The optional section filter implies scope, but fails to direct the agent to more specific alternatives.
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 carries the full burden. It only states 'List all available articles' without disclosing whether it is read-only, what 'all' means (e.g., pagination, limits), or any potential side effects. Minimal behavioral context.
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?
Two sentences efficiently convey purpose and parameter details. No fluff, but could be slightly improved with a note on return format or placement in a broader workflow.
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 low complexity (1 optional parameter) and presence of an output schema, the description is minimally adequate. It states the action but does not explain what fields the list contains or how results are structured, relying on the output schema.
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 parameter 'lang' is described with explicit allowed values ('pt', 'en', 'es') and a default ('pt'), adding meaning beyond the schema's type and default. However, no details on case sensitivity or format validation.
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 'List all available articles' uses a specific verb and resource, clearly indicating what the tool does. It distinguishes itself from sibling tools like 'get_artigo' (single article) and 'search_artigos' (search with filters).
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., 'get_artigo' for a specific article or 'search_artigos' for filtered queries). There is no mention of limitations or use cases.
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 disclose behavioral traits. It only states 'list all available glossary terms', implying a read operation, but does not explicitly confirm non-destructiveness, pagination, authentication requirements, or rate limits. Important behavioral details are omitted.
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 with only two sentences. The purpose is front-loaded, and every word adds value. There is no extraneous content, making it efficient for an AI agent to parse.
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 (one optional parameter, list operation) and the presence of an output schema (not shown but noted), the description sufficiently covers the tool's functionality. It lacks mention of ordering or size limits, but for a straightforward glossary listing, it is nearly complete.
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?
The input schema has 0% coverage, so the description must add meaning. It lists the 'lang' parameter with possible values 'pt', 'en', 'es' and a default. This adds value beyond the bare schema, but it does not explain behavior for invalid codes or how the language selection affects results.
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 'List all available glossary terms', specifying the verb 'list' and resource 'glossary terms'. This distinguishes it from siblings like 'get_glossario' (singular retrieval) and 'search_glossario' (search), which operate on the same resource but with different actions.
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. It does not mention that this returns the full list, while the sibling tools like 'get_glossario' retrieve a single term or 'search_glossario' performs filtered searches. The description lacks context for usage decisions.
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 carries full burden. It only states it searches by keyword, with no disclosure of behavior like result limits, ordering, or any restrictions.
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?
Very concise, front-loaded with a clear purpose statement, followed by a streamlined Arg section. Every sentence adds value without 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?
Adequate for a simple search tool with two parameters. Output schema exists but return format not described. Lacks behavioral details like pagination or authorization, but acceptable for minimal viable description.
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 description adds significant meaning: query parameter gets examples, lang parameter gets possible values and default. This compensates well for the lack of schema descriptions.
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 searches articles by keyword in title or body. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like 'search' or 'search_glossario'.
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?
Provides example queries and default language, giving implied usage guidance. However, no explicit when-to-use or when-not-to-use compared to alternatives.
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 description carries full burden. It does not disclose search behavior like exact vs fuzzy matching, pagination, rate limits, or what fields are returned. Only parameter examples are given.
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?
Description is very concise: one-line purpose followed by parameter documentation. No wasted words, front-loaded, easy to scan.
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?
Parameters are covered, but usage context, behavioral traits, and return value explanation are missing. Since output schema exists, return details are not required, but behavioral transparency lacks.
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?
With 0% schema description coverage, description adds meaning: query as 'Search term' with examples, lang with language codes and default. This compensates for schema's lack of description.
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 'Search thinker profiles by name or keyword', providing a specific verb and resource. It distinguishes from sibling tools like 'listar_pensadores' (which lists all) and generic 'search' by targeting thinker profiles explicitly.
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 vs alternatives such as 'search' or 'listar_pensadores'. The description implies searching by name or keyword but does not mention when not to use it or provide comparative 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?
No annotations are provided, so the description carries full burden. It only states it retrieves text, but does not disclose behavior on slug mismatch, response format (though output schema exists), or any side effects. 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?
The description is very concise: a one-sentence purpose followed by clear parameter descriptions. No wasted words, and the most important information is 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?
For a simple tool with two parameters and an existing output schema, the description covers the core functionality and parameter details. However, it lacks usage guidelines and behavioral context, making it adequate but not 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?
Schema coverage is 0%, so description adds significant value. It explains slug allows partial match with examples, and lang specifies permitted codes and default. This goes beyond the schema's type-only definitions.
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 'Get the full text of a period synthesis,' which uses a specific verb and resource. It distinguishes from sibling tools like listar_sinteses (which lists syntheses) and other get_* tools by specifying 'period synthesis.'
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 does not provide any guidance on when to use this tool versus alternatives such as listar_sinteses or search. It lacks information about 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?
With no annotations provided, the description carries full burden. It only states the tool lists all, but lacks details on return format, pagination, performance, or any side effects. Minimal behavioral disclosure.
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 with two sentences followed by an args section. It is front-loaded with the purpose and contains no unnecessary 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 is simple (list all profiles) and an output schema exists, the description is adequate. It sets clear context but could mention that it returns a list and the scope of 'all available'.
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 adds meaning to the 'lang' parameter beyond the schema (which only has type and default) by specifying allowed values 'pt', 'en', 'es' and a default. This compensates 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 lists all philosopher/thinker profiles, using the verb 'list' and specifying the resource. It distinguishes from siblings like 'get_pensador' (single) and 'buscar_pensador' (search).
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 does not provide any guidance on when to use this tool versus alternatives, such as when to list all vs. search or get a single profile. No when-not-to-use or context is given.
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, and the description does not mention any behavioral traits such as whether the tool is read-only, requires authentication, or has limits. The agent must infer safety from the search action alone.
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 concise and well-structured, with a clear header and parameter list. Every sentence adds value, and there is no superfluous content.
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 presence of an output schema, return value details are not needed. However, the description lacks information on pagination, result limits, or multiple result handling, which are important for a search tool.
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 adds meaningful information beyond the schema: query is explained with examples and lang specifies language codes and default. This compensates 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 searches philosophical terms in the glossary by keyword, specifying both the resource (glossary) and action (search). This distinguishes it from siblings like listar_glossario (list all) and get_glossario (get specific).
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 gives examples of queries but does not explicitly state when to use this tool versus alternatives like search or listar_glossario. Usage context is implied but not explicit.
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 full burden for behavioral disclosure. It correctly indicates a read operation but does not mention any potential side effects, performance characteristics, or conditions like caching. However, since the tool has no parameters and appears lightweight, the brief description is minimally acceptable.
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 that directly conveys the tool's purpose and the specific breakdown of statistics. No extraneous words; it is appropriately front-loaded and concise.
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 low complexity (no parameters) and the existence of an output schema (provided but not detailed here), the description covers the essential outputs: total entries, by section, by language. It does not need to elaborate further, as the output schema defines the return structure. A minor gap is the lack of mention of how to interpret the statistics, but overall sufficient.
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 has zero parameters, so schema coverage is effectively 100%. Per the rules, a baseline score of 4 applies when no parameters exist. The description adds no param info, which is acceptable as none are needed.
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 statistics about the philosophy corpus, specifying the breakdown (total entries, by section, by language). The verb 'Get' and the resource 'statistics about the philosophy corpus' are specific. Among siblings (mostly search/retrieval tools), none provide corpus-level stats, so it is well-differentiated.
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 description does not mention when not to use it or any alternative tools that might be better suited for specific queries. An agent would need to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It only states that it lists syntheses and accepts a language parameter. It does not indicate whether the operation is read-only, if there are pagination limits, or any other constraints beyond the basic function.
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 with no wasted words: one sentence for purpose and one for the parameter. It is front-loaded with the core action and resource, making it easy to parse quickly.
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 (one optional parameter, no required fields) and the presence of an output schema, the description covers the essential purpose and parameter. However, it lacks context about the output format (e.g., list of summaries) and whether any filtering or ordering is supported, leaving minor gaps for a complete understanding.
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 for 'lang' has no description (0% coverage). The description adds meaning by specifying allowed language codes ('pt', 'en', 'es') and the default value 'pt', which aids correct parameter usage beyond the schema's default property.
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 'list' and the resource 'philosophical period syntheses' with a defined scope ('Pre-Socratics through 20th century'). It distinguishes from siblings like 'get_sintese' (singular) and 'listar_pensadores' (plural of other entities).
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 listing all syntheses by period but does not provide explicit guidance on when to use versus alternatives like 'get_sintese' or exclusion criteria. No when-not-to-use or alternative suggestions are given.
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 carries the full burden for behavioral disclosure. It only states 'Get the full text,' implying a read operation, but does not mention any potential side effects, authentication needs, or rate limits. For a simple read tool, this is minimal but acceptable.
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 and front-loaded with the purpose in the first line. Parameter descriptions are direct and free of fluff, making it easy to parse quickly.
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 parameters, no nested objects) and the presence of an output schema, the description sufficiently covers what the tool does. It lacks only minor context about potential error conditions or expected response structure, which are likely covered by the output schema.
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 parameter descriptions add significant value beyond the schema (which has 0% coverage). They explain the slug parameter with an example URL and specify valid language codes with a default value, fully compensating for the missing schema descriptions.
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 'Get the full text of an article by slug,' specifying the verb (get), resource (article), and identifier (slug). It effectively distinguishes from sibling tools like get_pensador and get_sintese by targeting a different resource type.
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 needing an article's full text via slug, but it does not explicitly state when to use this tool over alternatives like search_artigos or listar_artigos. No exclusions or prerequisites are provided.
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 carries full burden for behavioral disclosure. It only states 'Get' implying a read operation, but does not elaborate on any behavioral traits such as authentication requirements, rate limits, or whether the tool is destructive. Minimal transparency beyond the basic action.
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 concise, front-loaded with the purpose in the first line, followed by a clean Args section. Every sentence is necessary and there is no wasted text.
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 parameters, no nested objects) and the existence of an output schema (which handles return value documentation), the description is largely complete. It could mention potential case sensitivity or error handling, but these are minor gaps for a straightforward retrieval tool.
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?
Schema description coverage is 0%, so the description must compensate. It does so effectively by explaining the 'slug' parameter with examples ('socrates', 'Kant', 'aristoteles') and the 'lang' parameter with explicit allowed values ('pt', 'en', 'es') and a default ('pt'). This adds significant meaning beyond the bare schema types.
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 'Get the full profile of a philosopher/thinker' with a specific verb (Get) and resource (full profile). It distinguishes from sibling tools like 'buscar_pensador' (search) and 'listar_pensadores' (list) by focusing on a single, full profile retrieval.
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 you have a specific slug (e.g., 'socrates') but does not explicitly state when to use this tool versus alternatives like 'buscar_pensador' for searching. It provides examples but lacks explicit when-not or 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?
No annotations are provided, so the description bears the full burden. It states it 'gets' a definition, implying a read-only operation, but does not explicitly disclose lack of side effects, rate limits, or what 'full definition' includes. It is minimally adequate for a simple retrieval 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 short, front-loaded, and structured bullet-style for arguments. Each sentence serves a purpose, with 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?
For a simple retrieval tool with an output schema (not shown but indicated), the input description is complete. The description covers the required parameters and their formats. It does not need to explain return values because the output schema handles that.
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 has 0% description coverage, but the description compensates by explaining 'slug' as a URL slug with examples and 'lang' as a language code with options and a default. This adds meaning beyond the schema property types.
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 'Get the full definition of a glossary term by its slug' and provides examples, which is specific about the verb and resource. It differentiates from siblings like listar_glossario (lists terms) and search_glossario (searches terms).
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?
Usage is implied by the name and description (fetch a single term by slug), but no explicit guidance on when to use this vs alternatives (e.g., listar_glossario for listing all terms). No when-not or exclusion conditions are stated.
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:

[![philosophy-mcp MCP server](https://glama.ai/mcp/servers/s3b4hjr/philosophy-mcp/badges/card.svg)](https://glama.ai/mcp/servers/s3b4hjr/philosophy-mcp)

Score Badge

Copy to your README.md:

[![philosophy-mcp MCP server](https://glama.ai/mcp/servers/s3b4hjr/philosophy-mcp/badges/score.svg)](https://glama.ai/mcp/servers/s3b4hjr/philosophy-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/s3b4hjr/philosophy-mcp'

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